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En la bibliografía computacional existen 
pocos textos que aborden el problema de la pro- 
ductividad de los recursos de cómputo. En la 
actualidad, muchos responsables de centros de 
procesamiento de datos al evaluar la productivi 
dad de los recursos empleados, detectan que 
éstos no han sido utilizados eficientemente, no 
se evalúan sus costos, se menosprecian sus bene- 
ficios y se conforman con una explotación defi- 
ciente de los sistemas. 

Administración de la función informática es cl 
resultado de muchos años de experiencia del 
ingeniero Hernández en la administración de 
centros de procesamiento de datos. En ella, el 
autor encara la problemática, la ubica en su real 
dimensión y expone la técnica para detectar y 
reducir el “despilfarro computacional”, asi como 
la mejor manera de organizar y plancar los 
recursos de cómputo, 

Los altos costos de la tecnología computacio- 
nal hacen imprescindible optimizar los recursos 
de procesamiento disponibles y minimizar los 
costos del sistema para que éste sea más renta- 
ble y productivo. Por todo lo anterior, el volu- 
men que aquí se presenta constituye un valioso 
auxiliar en el estudio de la teoría computacio- 
nal; está dirigido a profesores, profesionales y 
estudiantes de informática y computación, así 
como a aquellas personas que requieren una 
guía para planificar, organizar y optimizar los 
sistemas de cómputo, El contenido de la obra 
está estructurado en 22 capítulos, de acuerdo 
con los distintos niveles de importancia en el 
diagnóstico y detección del problema; se conti 
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Prólogo 


Este libro tardó en concluirse más de 15 años, aunque sólo me llevó 
algunos meses el escribirlo. Desde los principios de mi carrera en el ámbi- 
to del procesamiento de datos mediante equipos de cómputo —tuve la 
oportunidad de ejercerla a mediados de 1968=, comencé a ser partícipe 
de un fenómeno que prevalece hasta la fecha y que, aun cuando todos los 
que hemos trabajado en el medio lo conocemos bien, pocos hemos hecho 
algo para contrarrestarlo, permitiendo que cada vez sus efectos scan más 
devastadores. 

Este fenómeno se da por el mal uso que hacemos de los recursos de 
cómputo. Durante los últimos años he detectado el gran desperdicio que 
sufre esta tecnología, tan importante para cualquier país. Si bien es cierto 
que la heredamos, eso no nos autoriza a abandonar nuestra responsabili- 
dad y hacer lo posible para aprovecharla en su justa dimensión. Lejos de 
aceptar el reto con el afán de lograr un uso eficiente de lo que se nos ha 
dado, nos hemos acostumbrado a menospreciar sus beneficios; a obtener 
de ello lo que resulte, sin importar su costo; nos hemos conformado con 
una explotación deficiente. Dicho fenómeno lo he definido como “despil- 
farro computacional". 

Detectar las causas de este Fenómeno es lo que ha tomado tanto 
tiempo. Para esto fue necesario observar día con día los problemas de 
productividad a los que se enfrentan la mayor parte de las instalaciones. 
Ha sido fundamental apreciar sus causas y efectos, así como comprobar 
que tales problemas se repiten una y otra vez en la misma instalación y 
que a su vez éstos son idénticos en otras instalaciones. Fue definitivo 
haber vivido esos problemas uno a uno y ser partícipe de los fracasos a 
que conducen para tener la seguridad de que no son imaginarios sino 
reales. Fue necesario apreciar que los efectos de este problema son muy 
graves; al grado de ser la principal razón de nuestro atraso tecnológico 
en el ámbito computacional. En suma, la veracidad de lo que aquí se 
expone está sustentada por cientos de colegas que han tenido el valor de 
aceptarlos y atacarlos con verdadera persistencia; aunque ha faltado 
coordinación para hacer extensivos los procedimientos de solución que 
han tenido éxito. Por ello se puede decir que este libro ha sido escrito 
por más de un centenar de personas altamente calificadas y con amplia 
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experiencia, digna de tomarse en consideración para los objetivos de 
esta obra. 

No podría adjudicarme el mérito completo del presente trabajo por- 
que es de esos libros que no deben ser escritos por una sola persona. Su 
real valor es adquirido por cientos, si no es que por miles, de entrevistas, 
comentarios, opiniones, sugerencias, aportaciones, experiencias, análisis, 
trabajos, éxitos, fracasos, conclusiones y todo lo que hace posible su 
demostración; una realidad que se quiere reconocer con la profundidad 
necesaria y, finalmente, exponerla en forma abierta para que otros logren 
identificarla en su justa dimensión. Sin embargo, asumo la responsabili- 
dad de lo que aquí se expone porque es muy mía la tenacidad y constancia 
de haber desarrollado años de investigación, los cuales me han dado la 
madurez para discernir entre lo que se debe criticar con valor, por resul- 
tar un problema de raíz, y la capacidad para proponer soluciones realistas 
que amortigúen las consecuencias del “despilfarro computacional". 

Si el lector llega a sentirse aludido al darse cuenta que es partícipe de 
la raíz de algún problema aquí expuesto, le ruego reflexione y comprenda 
que un libro cuyo fin es atacar problemas en su máxima concepción, no 
tendría sentido si no fuera honesto y encubriera las causas del mismo, por 
incómodas que éstas resultaran. Al contrario, analice con detenimiento el 
problema y acepte la oportunidad que le ofrece de participar en su solu- 
ción. Ésta es la clave, usted no será un pasajero que cómodamente aborda 
la lectura de este libro y espera con placer que lo lleve a su destino sin nin- 
gún esfuerzo. Usted será el conductor, yo sólo le proporcionaré un mapa 
perfectamente comprensible para que con su esfuerzo y su capacidad 
intelectual llegue al destino marcado por el objetivo de este libro, el cual 
es reducir al máximo el “despilfarro computacional”, 

Sí, en efecto, usted será su propio conductor, pero le advierto que el viaje 
no será secillo: pasará por caminos casi inaccesibles; cruzará desiertos exten- 
sos, terrenos pantanosos, espesuras selváticas; habrá momentos en que no 
querrá continuar y quizás hasta sienta el deseo de regresar, pero cuando con- 
sulte su mapa guía se llevará una sorpresa, pues el trecho avanzado será muy 
grande y no le quedará más remedio que seguir adelante, a pesar de encon- 
trarse solo. Cuando finalmente casi exhausto, compruebe en su mapa guía 
que llegó a su destino, sólo encontrará una gran puerta que se abrirá en for- 
ma automática para cederle el paso. Cuando se encuentre del otro lado, ésta 
se cerrará por un mecanismo imposible de franquear si quisiera regresar. 
Para entonces usted se dará cuenta de que realmente ha sido un viaje sin 
regreso. Usted ya no será el mismo; habrá aprendido que existen muchas 
posibilidades de erradicar el “despilfarro computacional" que los medios 
están en sus manos y en su mente. Cuando vuelva la vista hacia adelante 
podrá ver un mundo ya conocido por usted, cuyo trayecto será mil veces más 
difícil que el camino recorrido. Podrá apreciar cientos de empresas que lo 
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esperan deseosas de contar con información clara, oportuna y veraz, que pet- 
mita a sus directivos conducirla hacia los millones de clientes que esperan un 
mejor servicio. Si mira hacia otro lado, distinguirá cientos de dependencias 
gubernamentales que le ofrecen la oportunidad de apoyarlas para que la 
información de la que hasta ahora carecen les permita incrementar la recau- 
dación fiscal, controlar en forma eficiente la prestación de servicios, abreviar 
los trámites burocráticos, reducir la corrupción mediante controles exactos, 
así como encauzar sus planes a corto, mediano y largo plazos. Por otro lado, 
usted encontrará muchos funcionarios públicos, incluido el primer manda- 
tario de la nación, deseosos de contar con información no falseada para diri- 
gir el país con más seguridad y con planes más precisos. Más allá distinguirá 
millones de personas, el pueblo, que le reclamará un gran esfuerzo para 
que aporte sus conocimientos y no siga dedicando su valioso tiempo a 
resolver trámites de toda índole. Por un momento usted se sentirá con- 
fundido, pero casi de inmediato recobrará su fuerza, su mente estará 
muy lúcida, y en ese momento usted aceptará el reto, confiando en que 
lo puede lograr, pues habrá adquirido muchas de las normas de la buena 
“educación informática”. Para entonces usted habrá reflexionado sobre 
la importancia de la información, que es en sí la que orienta las acciones 
en todo el mundo y mantiene la integración de la humanidad, Los 
acuerdos más importantes entre naciones dependen del grado en que 
cada una esté informada y, obviamente, de la calidad, veracidad y opor- 
tunidad de la información. 


Comentario a la tercera edición 


El gran interés que Administración de centros de cómputo ha desper- 
tado entre colegas y estudiantes me estimuló para continuar mis investi- 
gaciones. 

En esta tercera edición expongo nuevas conclusiones, tales como el 
concepto de "excelencia informática"; la importancia del “seguimiento 
como función”; la afirmación de que “los centros de cómputo no están 
administrados”; mi propuesta sobre el “modelo de aprendizaje por segui- 
miento como función”; un estudio completo sobre los argumentos de mis 
aseveraciones, etcétera. 

Me es grato decir que dichas investigaciones han sido recibidas con 
interés, y se les da ya importancia tanto a nivel nacional como internacio- 
nal. Deseo hacerlas extensivas a usted, estimado lector. 


Comentario a la cuarta edición 


Muchos de mis lectores y asistentes a mis conferencias y seminarios 
frecuentemente me habían invitado a que incluyera un tema que tratara 
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sobre el uso que se les ha dado a las microcomputadoras directamente en 
las áreas operativas de las empresas. Por algún tiempo no me decidí a 
hacerlo, porque precisamente me encontraba inmerso en una investiga- 
ción a este respecto. Ahora, finalmente al haber culminado dicha investi- 
gación, en esta cuarta edición, pongo a disposición de los lectores el análi- 
sis de la problemática ahí encontrada y, por supuesto, la propuesta de 
solución que permita a mediano plazo fomentar una “cultura informáti- 
ca" en esos sectores operativos de las empresas; lo cual, en otras palabras, 
significa iniciar la descentralización de la función informática de las 
empresas; opción que ya es reclamada por la dinámica acelerada con la 
que se mueven los modernos mecanismos administrativos y los requeri- 
mientos crecientes de información de los esquemas organizacionales tre- 
'mendamente móviles, los cuales día con día tratan de adaptarse a las pro- 
yecciones de las empresas, quienes ya vislumbran la complicada com- 
petencia que se avecina, 

Quisiera terminar este comentario agradeciendo a las múltiples em- 
presas y universidades de todo el país que me han solicitado el seminario 
denominado “Administración de la Función Informática de las Empre- 
sas”, basado en este libro, en el cual trato de alertar a mis colegas informá- 
ticos para prepararnos a desempeñar el papel tan importante que nos toca 
en la modernización de las empresas con miras a incrementar la producti- 
vidad del área de informática, y apoyarlas con los recursos de información 
requeridos para que las áreas operativas agilicen sus mecanismos adminis- 
trativos, a fin de que los clientes sean atendidos con un alto grado de cali- 
dad en el servicio que se les ofrece, logrando con lo anterior un nivel de 
competitividad capaz de ser congruente con los requerimientos a que, 
queramos o no, nos obliga el actual Tratado de Libre Comercio. 

Por lo anterior, mi editor y yo hemos decidido cambiar el título de 
este libro Administración de centros de cómputo por el de Administración 
de la función informática vinculándolo de esta manera, por su contenido, 
a la relevancia que está adoptando la materia en la época actual y en los 
años próximos. 

Finalmente, quiero responder a repetidas peticiones sobre la manera 
de establecer contacto conmigo para que me escriban sus sugerencias o 
para que participe en exposiciones sobre los temas de mi libro. Favor de 
dirigirse a: 


Ing. Ricardo Hernández Jiménez. 
Hacienda de la Trasquila Núm. 116 

Col. Haciendas de Echegaray 

Naucalpan, Edo. de México, C. P. 53300 
Tel. 560-23-40 
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Introducción 


Como resultado de sencillas charlas de café donde nos reuníamos 
varios compañeros del ambiente de cómputo, analizamos en un breve 
resumen en torno a qué habían girado nuestras múltiples pláticas; y algo 
que de momento nos impactó fue que, sin excepción, siempre habíamos 
comentado sobre problemas que sucedían en nuestros distintos centros 
de trabajo. La conclusión inmediata fue: todos los centros de cómp: 
nen problemas de operación. 

Esto nos inquietó cuando casi al unísono, nos preguntamos: ¿cuáles 
son las razones?; ¿qué es lo que pasa?; ¿hay manera de eliminarlos o por lo 
menos abreviarlos? Coincidimos en que teníamos que hacer algo al res- 
pecto, que la mayoría de nosotros podríamos aportar nuestra experiencia 
y, con un poco de suerte y mucha dedicación quizá encontraríamos la luz 
que permitiera detectar las razones de este mal y en la medida de nuestra 
investigación podríamos detectar soluciones realistas y dignas de ponerse 
en práctica. Sin embargo, volvimos a coincidir en una pregunta: ¿por 
dónde empezar? En esta ocasión nos retiramos llevando como tareá que 
en la siguiente reunión haríamos sugerencias de cómo comenzar con una 
investigación que nos llevara a lo que en ese momento denominamos 
“detectar los verdaderos problemas de nuestro ámbito computacional y 
exponer posibilidades de solución”. 

En la siguiente reunión, tal como lo acordamos, pusimos en tela de 
juicio nuestras sugerencias personales y, finalmente, concluimos sólo en: 
Llevar a cabo encuestas en diversas instalaciones, grandes y pequeñas, 
que previamente seleccionaríamos”. Así lo hicimos y como primer resul- 
tado tangible, reuniendo las conclusiones de las encuestas, publiqué un 
artículo en la revista Informática bajo el título “Los verdaderos problemas 
de nuestro ámbito computacional”, el cual expongo textualmente a conti- 
nuación: 


+ En la mayoría de las instalaciones de procesamiento de datos existen 
grupos de técnicos altamente calificados a quienes por lo general se denomi- 
na “soporte a la producción”. La función a de estos grupos es fungir 
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+4 como “bomberos” para los casos en que fallan los procesos en producción. 
De una manera casi heroica y contra el tiempo, ellos tienen la responsabili- 
dad de corregir esas fallas, ya sea reprocesando según entienden el proceso o, 
peor aún, haciendo "reparaciones improvisadas y sin control, que poco a 
poco deforman la estructura original de los sistemas; y sí agregamos que 
dichas reparaciones, por la premura con que se hacen, generalmente no se 
documentan, entonces la documentación original en caso de que exista, va 
perdiendo su relación con el sistema correspondiente, Así, reparación tras 
reparación, empeora la situación hasta el grado de hacer casi imposible la 
comprensión de cualquier sistema en su concepto integral; por tanto, los sis- 
temas afectados de tal manera se convierten en “bombas de tiempo", ponien- 
do en peligro la estabilidad de la instalación. 

Como es de suponer, las personas que participaron en la afectación de 
tales sistemas empiezan a ser indispensables porque sólo ellos saben en dór 
de hicieron ajustes. Entonces, el famoso grupo de “soporte a la producción’ 
adquiere sentido, pues existe un pretexto real que justifica su existencia, a 
pesar de que esto desquicia el buen funcionamiento de la organización, por- 
que a partir de ahí el centro de cómputo depende en gran medida de unas 
cuantas personas y, peor aún, nadie puede garantizar si la siguiente falla 
podrá ser resuelta. La consecuencia será que la instalación sea en todo 
momento “inestable”. 

¿Por qué “fallan” los procesos en producción? ¿No se supone que se 
tuvo el tiempo suficiente para analizar y diseñar de manera minuciosa los 
sistemas? ¿No se probaron en forma exhaustiva programa tras programa has- 
ta determinar que cubrían todas las condiciones establecidas en el diseño? 

No se revisaron y analizaron meticulosamente los resultados de las pruebas 
Arc soon psico al KAA KN Duc dl ésa integral, y 
se demostró con un plan de ejecución que era un sistema confiable para libe- 
rarse a producción? Entonces, ¿qué pasa? Las experiencias han demostrado 
durante mucho tiempo, aquí y en otros países, que los sistemas que se desa- 
rrollan en rigurosa forma, regidos por metodologías que eslabonan con fir- 
meza fase tras fase, difícilmente fallan, y que cuando esto sucede es por 
excepciones que de ninguna manera justifican a un grupo de técnicos alta- 
mente calificados y con sueldos muy altos, y menos aun cuando su trabajo 
consiste en deformar los sistemas originales. Los cambios necesarios alos si 
temas y las excepciones de falla deben tratarse bajo estricto control por per- 
sonas que conocen los detalles del sistema. 

Jamás se debe olvidar que tales correcciones afectan necesariamente a la 
documentación, lo cual hace que los sistemas sean operados y mantenidos 
en lo futuro. Pues lo importante no es corregir las fallas sino determinar de 
rigurosa manera la causa y prever que esto no vuelva a suceder. Sin embargo, 
esto implica por fuerza actividades serias y profesionales. 

Lo anterior demuestra que todavía no hemos madurado lo suficiente 
dentro de esta disciplina y que no seguimos lineamientos de trabajo seguros, 
aunque éstos existan. Olvidamos con frecuencia que la computadora no 
tolera errores humanos y que éstos son muy costosos tanto en tiempo como 

jero; además, desprestigian la labor de un centro de cómputo ante sus 
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propios usuarios, fomentando constantes fricciones sus anbos: Bo hay 
e olvidar que un usuario puede ser un cliente que acude a un banco a 
A rar un cheque o a pagar la prestación de algún servicio. 

'Loanterior es sólo uno de los males que, como enfermedades mortales, van 
minando la única y verdadera razón de los centros de cómputo: producir infor- 
ación veraz y oportuna, sin lo cual dichos centros deberían desaparecer, 

y 2 Sería inútil insistir en que la tecnología nos lleva la delantera y que no 
stamos preparados para obtener el máximo provecho de las computadoras 
Jectrónicas! Es común leer y escuchar que no hay gente en el mercado lo 
Cuficientemente experimentada y capacitada para ocupar puestos tecnicoad- 
"ministrativos importantes en este campo; y día con día podemos comprobar- 
lo mediante los múltiples anuncios que solicitan técnicos de alto nivel, que 
ofrecen sueldos altísimos y, aunque sabemos que esto propicia el pirateo, la 
rotación de personal, la inflación de sueldos, el descontento de los técnicos 
internos, etc., lo seguimos haciendo sin reconocer que eso no solucionará 
nuestros problemas, pues la deficiencia en el servicio sigue existiendo, aun 
cuando hay gente altamente experimentada. No es real que sólo personas 
con un nivel académico elevado sean capaces de desempeñar Funciones téc- 
nicas eficientes, pues existen jóvenes que aun con un grado académico 
medio son hoy los “pilares” en materia de cómputo de muchas instalaciones. 
A ellos debe dárseles oportunidades y no menospreciarlos. 

Para tener bases firmes acudimos a varias instalaciones, tanto grandes 
como medianas y pequeñas, e hicimos encuestas sobre cuáles, a juicio de los 
técnicos, eran las razones básicas que entorpecían la función efectiva de su 
centro de cómputo. Hay que destacar que en todas las instalaciones que visi 
tamos, de unao de otra manera, había serios problemas, así como situaciones 
de presión que, según los entrevistados, con frecuencia los ponían al borde 
de la crisis. Como resultado de tales entrevistas, encontramos las siguientes 
apreciaciones: 


1. La mayoría de los jefes de los centros de cómputo se comprometen a 
entregar resultados en tiempos récord, sin tomar en cuenta a quienes 
realmente hacen el trabajo. 

2. Si no son los jefes quienes se comprometen, por lo general tienen 
que aceptar los tiempos marcados por los directivos, pues aquéllos 
son impuestos, sin considerar el grado de dificultad de los trabajos, ni 
los recursos con que se cuenta. 

3. En gran, cantidad de instalaciones los técnicos aprenden sobre la 
marcha, de una manera por completo empírica y sin planes de capa- 
citación previamente definidos. Muchos de los técnicos se inseri 
ben por iniciativa propia en escuelas técnicas, costeando sus pro- 
pios estudios. 

4. Todo el tiempo se encuentran saturados de trabajo por falta de pla- 
neación efectiva, razón por la cual difícilmente realizan labor de 

| investigación, necesaria para la mejor explotación de los recursos 
de cómputo. 

5. Con frecuencia, los usuarios se sienten insatisfechos por la falta de 
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un nivel de servicio acorde con sus verdaderas necesidades de infor- 
mación, y en ocasiones están en completa discordia con el centro de 
cómputo. 

6. Existe gran escasez de personal con experiencia, y la mayoría de las 
empresas no pueden contratar el personal suficiente, 

7. No hay metodologías de trabajo, y donde llegan a existir, dificil- 
mente son respetadas. 

8. Los sueldos son muy desiguales, tanto en la propia instalación 
como de una a otra, lo que provoca bastantes insatisfacciones per- 
sonales. 


Como se puede apreciar, la problemática real está a la vista de todos y no 
en los recursos de cómputo como se pretende, Más bien creemos que la raíz 
de todos estos desajustes es la falta de coordinación, motivación y disciplina, 
factores indispensables en el ámbito computacional. 


El resultado de nuestras encuestas queda sintetizado así. Sin embar- 
go, no quisimos conformarnos con exponerlo y criticarlo, porque ésta es 
tarea sencilla, sino que conjuntamos más información e hicimos un análi- 
sis más severo cuyo producto final ponemos a consideración del lector a 
través de este libro. 

Cabe aclarar que el contenido de la presente obra no sólo se limita a 
mencionar la problemática del medio, sino que en cada tema sugiere 
estrategias de solución plenamente probadas en la práctica. Sin embargo, 
no se piense que tales sugerencias son mágicas ni predican cambios auto- 
máticos e instantáneos para aquellos que previa evaluación decidan adop- 
tarlas. Más bien, lo que se visualiza es un conjunto de actividades que 
pueden ser implantadas de manera paulatina y ordenada, De la misma 
forma, son factibles de acoplarse a las necesidades individuales de cada 
instalación. 


1 


La administración de 
los centros de 
cómputo: una actividad 
urgente 


Problema 


La administración de las centros de 
cómputo es una actividad urgente. 


La tecnología de la computación electrónica ha modificado de 
anera importante la forma de trabajar de toda la humanidad. La 
dependencia que tenemos en la actualidad de las computadoras es evi 
dente. Sin embargo, los sucesos han ocurrido con tal rapidez que se 
requiere de un análisis formal para comprobar la magnitud de esta 
dependencia. Una manera drástica, pero muy objetiva de ilustrarla, 
sería imaginar lo que podría suceder si de un momento a otro se desco- 
nectaran todas las computadoras en el mundo. Los efectos serían más 
graves que los causados por una guerra. De inmediato, quedaríamos sin 
transportes ni comunicaciones, los bancos cerrarían y no habría dinero 
disponible, las transacciones comerciales quedarían prácticamente anula- 
das, la mayoría de las empresas dejarían de prestar sus servicios y mi uchas 
otras detendrían su producción, grandes redes de suministros de energía 
eléctrica quedarían desactivada, los suministros de agua dejarían de ope- 
rar, millones de personas quedarían inactivas, etcétera, 

Lo anterior seguramente no sucederá, pero nos permite evaluar la 
importancia de las computadoras. Y si bien no llegará a suceder en tan 
gran escala, es innegable la frecuencia con que somos víctimas de los erro- 
res que se cometen en los centros de cómputo. ¿Quién no ha perdido 
horas esperando a que se restablezcan los servicios de algún banco a fin de 
cobrar un cheque? ¿Cuántas veces no hemos acudido a aclarar un recibo 
de cobro emitido erróneamente? Miles de trámites han quedado pendien- 
tes por falta de información oportuna. 
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Si cuantificáramos en dinero el costo de esos errores nos daríamos 
cuenta de que son quizá los errores más costosos actualmente. Un error 
de este tipo, aunque parezca insignificante, afecta a mucha gente en 
sólo un momento, en razón del servicio masivo que representan dichos 
centros. 

Lo anterior obliga a pensar que algo está sucediendo en el ámbito 
informático. Mejor dicho, siempre ha sucedido, pero ha sido tan sutil que 
pocos nos hemos percatado de semejante riesgo. No es admisible que si la 
función de un centro de cómputo es simplificar las labores administrati- 
vas, éstas en muchos casos terminen por ser más complicadas. 

Mis actividades como asesor en informática de los centros de cómputo 
más grandes de el país me han demostrado que la causa real de estos proble- 
mas está en un bajo nivel administrativo de los centros de cómputo. Confie- 
so que no fue fácil llegar a esta conclusión; tomó muchos meses de investi- 
gación, Sin embargo, antes de adentrarnos en este punto, fijemos nuestra 
atención en lo que es un centro de cómputo, ya que esto permitirá una 
valoración más amplia del problema administrativo que allí ocurre. 

Un centro de cómputo representa una entidad dentro de la organiza- 
ción, la cual tiene como objetivo satisfacer las necesidades de información de 
npresa, de manera veraz y oportuna. Su función primordial es apoyar la 
labor administrativa para hacerla más segura, Huida, y así simplificarla, El 
centro de cómputo es responsable de centralizar, custodiar y procesar la 
mayoría de los datos con los que opera la compañía. Prácticamente todas las 
actividades de los demás departamentos se basan en la información que les 
proporciona dicho centro. La toma de decisiones depende en gran medida 
de la capacidad de respuesta del proceso de datos, Por lo anterior, casi no se 
escatima la inversión para proveerlo del equipo técnico (material y humano) 
necesario. De hecho, en la mayoría de las organizaciones el centro de 
cómputo absorbe la mayor parte del presupuesto. La importancia que tiene el 
centro de cómputo dentro de la organización, lo coloca en una posición que 
influye incluso en una gran parte de las decisiones administrativas y de pro- 
yección de las empresas. 

Como se puede apreciar, el centro de cómputo es uno de los engranes 
vitales dentro de la maquinaria organizacional; permite que muchos otros 
engranes se detengan o funcionen sistemáticamente. De hecho, un centro 
de cómputo significa la culminación de la sistematización de la empresa. El 
análisis y diseño de sistemas de información implica un alto grado de efi- 
ciencia administrativa dentro de la organización, de lo contrario dificil- 
mente se podrían llevar a la práctica los diseños. Se puede afirmar que el 
centro de cómputo reclama que los mecanismos administrativos de la orga- 
nización estén claramente establecidos. Aún más, si no lo estuvieran, dicho 
centro está preparado para colaborar a fin de establecerlos. En otras pala- 
bras, el centro de cómputo predica la buena administración. 
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Hasta aquí toda va bien. Es conveniente, o más bien diría, indispensa- 
ble para un centro de cómputo, hacer lo necesario antes de iniciar el aná- 
sy diseño de los sistemas, para que la empresa tenga un nivel adminis- 
trativo eficiente. Pero aquí surge una pregunta: ¿Está preparado 
administrativamente el centro de cómputo para asumir su gran responsa- 
bilidad? y 

La experiencia que he adquirido durante más de 15 años en el ámbito 
informático me ha demostrado que pocos centros de cómputo están efi- 
“entemente administrados. En la mayoría existen serios problemas al res- 
pecto. La falta de administración conlleva a un despilfarro de los recursos 
He cómputo, tanto humanos como materiales. He observado que la causa 
más Frecuente de los errores que se cometen en estos centros e: la falta de 
administración. 

He realizado auditorías técnicas en distintos centros de cómputo para 
detectar innumerables deficiencias en su operación. Al principio era relati- 
vamente las causas individuales de los errores e implantar 
los correctivos. Si bien mejoraba en gran medida la operación y se resolvían 
temporalmente los problemas y, durante un tiempo todo parecía estar bajo 
control, después, errores que no se habían presentado surgían como por 
arte de magia. Esto me inquietó, porque parecía que nunca podríamos ade- 
lantarnos, o por lo menos, amortiguar las consecuencias de tales errores. 

Dediqué mucho tiempo para encontrar un método realmente efecti- 
vo que cubriera la mayoría de las posibilidades de solución de errores pre- 
viamente identificados; pero a medida que avanzaba en el análisis llegué a 
la conclusión de que no era imposible encontrar un metodo único real- 
mente satisfactorio, porque mientras se ajustaba a la solución de cierto 
tipo de errores, por otro lado resultaba incongruente como solución de 
otra clase de errores; es decir la solución integral no podía enmarcarse en 
una sola estrategia. 

Decidí cambiar mi método de análisis del problema. Deduje que 
mientras no conociera las causas originales que habían propiciado esta 
situación sería muy complicado encontrar una solución efectiva y, sobre 
todo, permanente. Me imaginé que esas causas deberían estar en el hi 
rial mismo del centro de cómputo. En ese tiempo asesoraba a una de las 
instalaciones más grandes del país y pensé que ésta era un excelente pro- 
totipo con la cual podía iniciar la investigación. Con la ayuda de los direc- 
tivos obtuve toda la información posible y encontré lo siguiente: 


1. Cinco años antes, la organización del centro de cómputo contaba 
con las siguientes áreas: 


+ Análisis y diseño de sistemas. 
+ Unidad de programación. 
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« Unidad de operación. 
+ Soporte técnico. 


El área de análisis y diseño de sistemas se encargaba de definir los pro- 
gramas de cada sistema, Elaboraba un documento bien estructurado en 
donde se encontraba lo concerniente a cada programa y lo enviaba a la 
unidad de programación 

En la unidad de programación se estudiaba la definición de cada pro- 
grama y se aclaraban dudas con el analista correspondiente. Se procedía a 
elaborar el programa y se regresaba al analista una carpeta con los resulta- 
dos de la última prueba y el listado fuente del programa. Como los datos 
prueba habían sido definidos por el analista, las cifras de control eran 
verificadas con facilidad por éste, quien había considerado todas las pos 
bilidades de combinación de datos a las cuales se apegaría el programa en 
producción. La carpeta que se enviaba al analista formaba parte de la 
documentación del sistema; otra carpeta propia para la operación del pro- 
grama se entregaba a la unidad de operación. 

La unidad de operación mantenía estrecha comunicación con los 
analistas de sistemas y con los usuarios para determinar los calendarios de 
producción. 

Finalmente, el área de soporte técnico se encargaba de mantener en 
operación el sistema operativo y de asesorar técnicamente a las demás 
áreas, 

2. Tres años antes, la organización del centro de cómputo tenía las 
mismas cuatro áreas; pero se incrementaron sus funciones, y el personal 
había aumentado de 17 personas a casi 25 en ese tiempo. Las áreas se 
estructuraban como sigue: 


+ Análisis y diseño de sistemas. 


-Sistemas locales. 
Sistemas on line. 


Unidad de programación. 


-Programadores de sistemas locales. 
-Programadores de sistemas on line. 


+ Unidad de operación. 


-Operadores de computador. 
-Operadores de la red on line. 
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+ Área de soporte técnico. 


-Sistemas Operativos. 
-Software on line. 


Por supuesto, los sistemas on line vinieron a establecer especialidades 
y variaron los procedimientos de control; se definieron nuevos estándares 
de trabajo; hubo necesidad de implantar planes de capacitación; el núme- 
ro de usuarios se incrementó; los calendarios de trabajo variaron notable- 
ro snte porque algunos sistemas batch se convirtieron en on line; se incre- 
mentó el equipo de cómputo , y aumentaron las cargas de trabajo en todas 
las áreas por la inclusión de nuevos sistemas y servicios. 

3. Un año antes, la organización volvió a cambiar de la siguiente 
manera: 


+ Análisis y diseño de sistemas. 


stemas locales. 
stemas on line, 
-Sistemas especiales (data base). 
—Mesa de control. 


+ Unidad de programación. 


—Programadores de sistemas locales. 
-Programadores de sistemas on line. 
-Programadores de data base. 
—Mesa de control. 


+ Unidad de operación. 
-Operadores de computador. 
-Operadores de periféricos. 
-Operadores de la red on line. 
-Control de la producción. 

e Área de soporte técnico. 
-Sistemas operativos. 
-Software on lime. 

—Software data base. 


+ Área de capacitación. 
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Esta nueva organización cambió prácticamente todos los procedi- 
mientos de control; métodos de trabajo; funciones; responsabilidades, 
cuotas de producción; horarios de servicio; hubo más usuarios; planes de 
capacitación, etc. Para entonces, el personal del centro de cómputo reba. 
só los cuarenta empleados. 

En el momento de llevar a cabo mi estudio, acerca del porqué de la 
cantidad de errores, la organización era la siguiente: 


+ Ánalisis y diseño de sistemas. 


=5 departamentos especializados por tipo de sistema aplicativo; 
cada uno atendía sistemas locales, on line y micros. 


+ Unidad de programación. 


—Programadores batch. 
-Programadores on line. 
-Programadores de micros. 
-Programadores de sistemas operativos. 
-Programadores de data base. 

Mesa de control. 


+ Unidad de operación. 


=Operadores especializados en periféricos, computadora y red on 
line. 

=Operadores de sistema 

—Control de la producción. 

-Operadores del centro de captu 

— Ingeniería de instalaciones. 


e Asesoria técnica. 


—Auditoría de sistemas. 
-Asesoría a usuarios. 


+ Seguridad de datos. 
+ Área de capacitación. 
+ Área de métodos y procedimientos. 


Para entonces, la cantidad de controles era muy complicada y confu- 
sa, las funciones y responsabilidades no eran muy claras y había desacuer. 
dos; eran 70 empleados. 


m 


¿Qué había sucedido? 


Después de la investigación, detecté que dentro de una organización 
a dela empresa) había nacido otra organización (la del centro de cómpu- 
Ue Era evidente que el centro de cómputo se estructuró por etapas; que 
organización se creó de manera improvisada. Pude distinguir que cada 
Su de autoadministraba con una independencia casi total. Por más 
fre erdos que se establecían entre las distintas áreas, era muy difícil regu- 
Tarla operación integral del centro de cómputo. Y cuando alguna área tra- 
bajaba correctamente, otra u otras fallaban debido a que se daban por 
hechas algunas actividades que ni siquiera se habían considerado, puesto 
quese presuponía que alguna otra área era la responsable de ellas, De esta 
manera, los errores aumentaban y surgían fricciones de una a otra área. 
Se comprobó que el centro de cómputo no estaba administrado. 
Comparé este estudio con la situación que se presentaba en algunos 
otros centros de cómputo y fue sencillo detectar los mismos problemas en 
ellos. En algunos centros que aparentemente trabajaban bien, lo estaban 
logrando gracias a un tremendo esfuerzo de coordinación entre las distin- 
tas áreas. En estos casos, diariamente se celebraba un sinnúmero de juntas 
de trabajo para lograr acuerdos. Esto provocaba gran consumo de tiempo 
en la toma de decisiones y la consecuencia era que el avance de muchos 
proyectos se interrumpía constantemente. 

De inmediato establecí que se estructurara un área exclusiva para la 
administración del centro de cómputo, cuyo objetivo fuera implantar un 
proceso administrativo completo, en el cual se considerara a la organiza- 
ción del centro de cómputo en su entorno global, así como los múltiples 
canales de comunicación con las distintas unidades usuarias de la compa- 
ña. Que estableciera puntos de control mediante los cuales se detectaran 
en forma oportuna desviaciones para estar a tiempo de operar correctivos 
plenamente predefinidos antes de que algún error surgiera e incrementa- 
ta los daños con el tiempo. 

Demostré que por la autonomía con que trabajaba cada área dentro 
dela organización del centro de cómputo, no sólo se entorpecía la puesta 
en práctica de soluciones que aisladamente se proponían para corregir 
ciertos errores, sino que se provocaban confrontaciones continuas. Com- 
probé que innumerables acuerdos entre las distintas áreas quedaban en el 
olvido por la falta de seguimiento efectivo; porque, por lo general, cada 
área establece sus propias prioridades de trabajo, y mientras unas áreas 
están en posibilidades de cumplir con su parte del acuerdo, otras no lo 
están por diversas razones, justificables e injustificables. 

Encontré que en actividades vitales del centro de cómputo no había 
procedimientos de trabajo, lo cual originaba una alta tendencia a la 
improvisación y a la falta de estandarización. En algunos casos los proce- 
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dimientos existían, pero no se respetaban ya sea por negligencia o por 
estar desactualizados. La documentación en algunas áreas era completa y 
práctica, mientras que en otras se carecía de ella, lo que permitía que los 
conocimientos y la experiencia los aprovecharan empleados que después 
renunciaban, ocasionando altos riesgos y, por supuesto, errores y pérdida 
considerable de tiempo hasta que los nuevos integrantes dominaban su 
trabajo. 

Comprobé que todos estos descontroles eran cabos sueltos que siem- 
pre habían existido en la instalación. También detecté que cada área tenía 
Funciones y responsabilidades concretas en las cuales no estaban conside- 
radas actividades administrativas claras y congruentes con las demás 
áreas. Más bien, éstas se habían implantado con una visión personalizada 
de cada área y por iniciativa de sus gerentes, pero no con una guía general 
que realmente se adaptara al esquema organizacional del centro de 
cómputo. 

Con todos los argumentos anteriores, irrefutables, elaboré un docu- 
mento que contenía la “Estructuración del área administrativa del centro 
de cómputo”. Ese documento consideraba las funciones y responsabilida- 
des prioritarias, de tal manera que dicha área fuera susceptible de una 
rápida formación y de obtener los beneficios a corto plazo. Propuse que 
ésta debería quedar ubicada como staff de la dirección del centro de 
cómputo, a fin de darle la autoridad suficiente para implantar sus estrate- 
gias y hacerlas respetar mediante un adecuado seguimiento. 

Mi propuesta, a pesar de no tener argumentos de peso en contra, se 
tomó con mucha cautela, y por un tiempo se archivó. El centro de cómpu- 
to siguió inmerso en graves problemas, y aunque se han realizado cons- 
tantes cambios en su organización, no ha sido suficiente. Después de 
muchos contratiempos, actualmente mi estrategia se considera como una 
decisión impostergable. 

Este libro ofrece un amplio panorama para distinguir hacia qué acti- 
vidades importantes se debe encausar la administración de los centros de 
cómputo. Estoy convencido de que el lector podrá imaginar ideas com- 
plementarias que le permitan pensar en áreas de aplicación adicionales, 
que a su vez lo impulsen en distintas direcciones dentro del entorno 
administrativo informático. Esto será de incalculable valor. 

Es urgente reconocer que las actividades de un centro de cómputo 
son muy distintas (y, por supuesto, no digo que más importantes) al resto 
de las áreas de una empresa. Quiérase o no, esta tecnología es nueva en 
nuestro medio, y esto nos enfrenta al hecho de que tomará tiempo com- 
prender sus beneficios, sus exigencias y sobre todo sus riesgos. No es 
admisible que algo tan delicado se deje a la deriva. 

Así como existen profesionales especializados en administración de 
empresas, en la actualidad es muy importante que haya profesionales 


DIDo? 27 


i QUE HABÍA SUC 


jalizados en administración de centros de cómputo. Sugiero que a 
Lo estudiantes de las carreras de informática por lo menos se les imparta 
una materia que considere dicha actividad. Sin embargo, no quiero pecar 
Me optimista; reconozco que esto depende de las autoridades académicas y 
ess podria lograr de un momento a otro. Por ello, en espera de que suce- 
Me, invito a los catedráticos de la materia a que, basados en sus experien- 
cias, dialoguen con sus alumnos y los hagan conscientes de la importancia 
de la administración en los centros de cómputo. Aconsejo a los estudian- 
tes que investiguen al respecto y hagan partícipes a sus maestros. Estoy 
seguro de que el tema abrirá un amplio panorama de aplicación a los egre- 
sados de estas carreras. 

Dado el auge de la computación y su sorprendente avance, las activi- 
dades dentro de un centro de cómputo se han diversificado tanto que 
obligan a que su esquema organizacional sea muy dinámico porque aqué- 
lla origina cambios notables en lapsos muy breves. Reitero que si no se 
afianza administrativamente, el centro de cómputo será inestable en todo 
momento y tendremos que seguir haciendo frente a innumerables erro- 
res, y soportar sus graves consecuencias y altos costos. 

¡La administración de los centros de cómputo es una actividad urgente! 


La importancia de 
evaluar los 
compromisos de trabajo 


Problema 


La mayoría de los jefes de los centros 
de cómputo se comprometen a entregar 
resultados en tiempo récord, sin tomar en 
cuenta a los que realmente hacen el trabajo. 


iste problema es muy común puesto que el nombramiento de jefe 
utomáticamente representa “don-de mando”. Esto no sólo es válido en 
el ambiente de cómputo, sino en cualquier compañía o institución. 
Cuando se trata de dirigir obreros, empleados o peones que realizan 
les, la estrategia resulta efectiva porque por lo general 
desempeñan actividades repetitivas y constantes que no representan 
mucho razonamiento y que, dependiendo de una supervisión muy 
estrecha, se ejecutan más rápido, con lo que se obtiene una mayor pro- 
ducción. Pero esto no sucede en un centro de cómputo, en donde el ver- 
dadero trabajo es resultado del factor creatividad, ¿Cómo es posible 
saber si un analista de sistemas está pensando en la solución que le dará a 
su diseño? ¿Cómo saber si un programa va a funcionar correctamente 
cuando sólo ha sido codificado en papel? 

No es posible saberlo. Entonces, se aprecia que el “don de mando" no 
garantiza resultados correctos ni oportunos; sin embargo, no son pocos los 
jefes que creen que así obtendrán mejores logros. En ocasiones se piensa 
ue por el solo hecho de tener un título académico, aun sin ser afín al área 
de computación, se está en posibilidades de dirigir un centro de cómputo, 
lo cual tampoco resulta cierto. Así pues, no es difícil reconocer que cuando 
algunos jefes aceptan compromisos para ser cumplidos en tiempos récord, 
lo hacen con desconocimiento del esfuerzo que eso requiere. Los resulta 
dos de esta estrategia los conocemos todos: noches sin dormir; trabajo fre- 
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te en fines de semana; sistemas al vapor e incompletos; deserción de 
euen nal, prórrogas en los tiempos de terminación o cancelación defini 
De proyecto. Los que conocemos este ambiente, de una o de otra manera 
o articipado en tales “maratones” y sabemos muy bien que son muy 

VE trabajos de este tipo que han culminado con éxito. La mayoría 
Palo han representado pérdidas cuantiosas, tanto en tiempo como en dine- 
Se demás del descontento y la falta de motivación general de quienes par- 


ticiparon 


SUGERENCIAS DE SOLUCIÓN 


1. Un jefe deberá ser una persona con conocimientos técnicos 
suficientes para que éstos le permitan evaluar la magnitud y comple- 
jidad de un proyecto, antes de adquirir un compromiso ante superio- 
res o usuarios 

2. Deberá tener la capacidad técnica suficiente para desglosar en 
macroactividades el esquema total del proyecto. 

3. En función de las macroactividades, él mismo deberá evaluar los 
recursos técnicos y humanos que se requerirán para realizar dicho proyecto. 

4. Una vez evaluado lo anterior, tendrá los elementos suficientes para 
determinar si cuenta con dichos recursos. En caso de contar con éstos, 
pasar al siguiente punto; de lo contrario, deberá tomar una posición sin- 
Cera y comunicar a sus superiores la situación. 

5. Si cuenta con los recursos necesarios, la situación es más cómoda; 
sin embargo, antes de comprometerse a dar fechas de terminación, deberá 
asignar las macroactividades al personal que designe, y dejar que ellos 
sean quienes, al descomponer cada macroactividad en actividades de 
detalle, determinen las fechas de terminación; y así, al conjugar todas 
éstas, tendrá una visión más realista del periodo total requerido para la 
terminación completa del proyecto. 

6. Es conveniente destacar que cada actividad resultante del desglose de 
las macroactividades deberá apegarse a la política de “productos terminados"; 
es decir, la terminación real de cada una deberá estar representada por algo 
tangible que permita visualizar su verdadera terminación. Normalmente un 
producto confiable es la documentación fiel que comprueba los resultados 
obtenidos al finalizar cada actividad. 

Es frecuente la creencia de que algunas actividades no se pueden 
medir con la política de “productos terminados"; sin embargo, la expe- 
riencia demuestra que toda tarea productiva arroja un resultado objetivo. 
Para comprobarlo se expone el siguiente ejemplo: 

Supongamos que a un programador se le designe para realizar un 


30 CAP. 2. LA IMPORTANCIA DE EVALUAR 


estudio sobre la instalación de un paquete de software. La pregunta que 
surge es: ¿cómo saber que el programador ya lo estudió? Hay varias for- 
mas de averiguarlo: se le podría solicitar que dé una plática sobre la estra- 
tegia de instalación; o bien que entregue una lista de verificación (check 
list) de las fases que seguirá para instalarlo. 

7. Un jefe deberá ser capaz de detectar que, desde el punto de vista 
técnico, las fechas de terminación programadas por sus subordinados no 
estén demasiado holgadas, ya que si esto sucediera podría resultar que la 
persona a quien se le hayan asignado tales actividades no sea la idónea; 
quizá su falta de experiencia la lleve a establecer plazos más largos de lo 
necesario. 

Esta no es una tarea fácil, pero es en estos casos donde el jefe demues- 
tra su habilidad de mando, con razones a la altura de cualquier técnico, y 
que ha sido designado para ese puesto por su experiencia y no por otras 
razones. Sin duda, esto lo hará más respetable. 

8. Por último, es función del jefe establecer controles de avance y segui- 
miento de proyectos, ya que esto le ayudará a visualizar las desviaciones 
imprevistas que pudieran surgir, y así establecer correctivos oportunos. 

En este punto hay que destacar que para el logro completo de todo 
proyecto, el jefe debe abstenerse de asignar actividades extras que desvien 
de su objetivo al personal ya asignado, ya que esto ocurre con frecuencia y 
entorpece las actividades normales, propiciando que el trabajo planeado 
se haga a medias y que el personal se sienta frustrado. Algo que se debe 
tener siempre en mente es el respeto al trabajo de cada miembro del equi- 
po, pero sobre todo, que vean la realización final del mismo. El hecho de 
sentirse productivos los motivará. 

Durante nuestras encuestas detectamos que los jefes de los centros de 
cómputo que de alguna manera observaban las sugerencias anteriores, 
invariablemente conseguían buenos resultados. Esto no quiere decir que 
en sus instalaciones no hubiera problemas; sin embargo, los beneficios de 
estas estrategias se podían palpar al comprobar que la mayoría de los téc- 
nicos casi no tenían necesidad de trabajar a deshoras ni los fines de sema- 
na, pese a que las cuotas de producción del centro de cómputo eran eleva- 
das, y claramente se distinguía un aire de tranquilidad y confianza, en 
contraste con otros centros en donde el desorden era evidente. 


RESUMEN DEL CAPÍTULO 2 


El “don de mando” no garantiza buenos resultados en un centro de 
cómputo. Cuando algún jefe se compromete a entregar resultados en 
tiempo récord y no toma en cuenta a los que realmente harán el trabajo, 
esto se debe a su falta de conocimiento del esfuerzo que ello implica, 
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El don de mando no hará que las cosas salgan mejor en un centro de 
cómputo. 


generándose así “maratones” que obligan a trabajar a marchas forzadas y 
en forma improvisada. La mayoría de estos trabajos tienden al fracaso, por 
lo que representan pérdidas cuantiosas tanto en tiempo como en dinero. 
Un jefe debe estar preparado para discernir la complejidad real de un tra- 
bajo antes de comprometer a otros. Deberá tener la capacidad técnica 
para comprender la magnitud de cualquier solicitud y no deberá aceptar 
compromisos sin antes dialogar con sus subordinados. Deberá estar segu- 
to de contar con los recursos técnicos y humanos disponibles para cum- 
plir el trabajo bajo rigurosa planeación, sin que los técnicos descuiden 
actividades a las cuales ya estén asignados. 


Estandarizamdo la 
comunicación entre 
directivos y técnicos 


Problema 


Si no son los jefes los que se 
comprometen, con frecuencia tienen que 
aceptar los tempos marcados por los 
directivos de la empresa, pues aquéllos 
son Impuestos sin considerar el grado de 
complejidad técnica y. a veces. ni los 
recursos con que se cuenta 


Se trata básicamente de un problerraa de comunicación entre técnicos 
y directivos, pues sencillamente no hab Lan el mismolenguaje; es decir, los 
directivos en su mayoría son administr adores quetenden a visualizar la 
proyección de su empresa. A ellos compete, en esencia, el ámbito del 
negocio y las relaciones con los distribua idores, clientes, etc. No está den- 
tro de sus actividades visualizar el aspe=cto técnico de un proyecto, ni la 
complejidad técnica que esto implica. Sin embargo, es fundamental que 
cuenten en forma oportuna con la infarmación que les provee el centro 
de cómputo, para que puedan tomar d ecisiones con más seguridad. Las 
imposiciones que se mencionan en la problemática de este plantamiento, 
son generadas, en forma fundamental, P>orque los directivos no compren- 
den el ámbito computacional, o tiener una idea desvirtuada, Con fre- 
cuencia creen que las computadoras so -n equipos automáticos que gene. 
ran fácilmente lo que se les solicita. Este problena se agudiza más aún 
cuando los directivos no tienen contacto con las labores del centro de 
cómputo. 

Debemos estar conscientes de que los directivos no son responsables de 
que este problema se presente, sino que tax-nbién intenienen los jefes que pre- 
paran presentaciones en el centro de córiputo sólo pera mejorar su imagen 
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ante los directivos. Ellos jamás comentan lo complejo que resulta preparar 
dicha presentación; por el contrario, disfrazan el proceso, haciéndolo parecer 
muy simple. Quienes conocemos el ambiente, hemos sido testigos y participes 
de frecuentes desvelos, convertidos en días y semanas agotadoras, a fin de pre- 

rar una presentación que no dura más de 15 minutos y que muchas veces es 
Cancelada. Por supuesto, con este tipo de trabajo se minimiza el esfuerzo que se 
requiere para mantener en operación un centro de cómputo. Existe un con- 
cepto desvirtuado de los directivos que exigen el cumplimiento de algún traba- 
joen tiempo récord, lo cual es producto de lo que en ellos han fomentado algu- 
nos jefes con poca responsabilidad. 


SUGERENCIAS DE SOLUCIÓN 


1. Es labor de todo jefe preparar seminarios técnicos básicos a fin de 
sensibilizar a los directivos. Tales seminarios se deben realizar para difun- 
dir, por medio de conceptos básicos, las ventajas de sus propios equipos 
de cómputo, así como las funciones técnicas que desarrolla el personal, 
con objeto de que los directivos puedan, por un lado, conocer realmente 
las posibilidades de los equipos de cómputo y, por otro, los requisitos de 
especialización que debe cubrir el personal técnico para lograr la funcio- 
nalidad y estabilidad del centro. En este punto, hay que destacar que hoy 
en día ya no es posible que ninguna persona, trátese de un directivo, pro- 
fesional, Funcionario, empleado o estudiante, ignore la verdadera función 
de las computadoras, sus alcances y sus requisitos. Es un conocimiento 
obligado para las generaciones actuales y futuras. 

Mediante esta estrategia, los directivos podrán visualizar, aunque en 
un esquema muy general, tanto el potencial real con que cuenta su centro 
de cómputo, como las deficiencias que existan. De esta manera, antes de 
exigir, podrán evaluar, dialogar y entender en qué medida harán sus soli- 
citudes de información. 

2. Otro factor importante es que en ciertos periodos los jefes deben 
informar a los directivos sobre los proyectos en los que se está trabajando; 
la importancia y beneficios que representan para la compañía; los recur- 
sos que tienen asignados, tanto de personal como de equipo; y cualquier 
información útil que permita saber a los directivos hasta qué grado se tie- 
nen comprometidos tales recursos, y si hay o no disponibilidad para 
absorber nuevos proyectos. Con esto, los directivos podrán asignar con 
más precisión las prioridades de cada proyecto. 

Es importante recalcar que en estos informes nunca se debe preten- 
der ocultar la situación real de la instalación, pues es más beneficioso que 
los directivos conozcan la verdad, por grave que ésta sea, y se tomen medi- 
das correctivas a tiempo, que hacerlos pensar que todo marcha a la perfec- 
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ción y que la instalación es una fuente inagotable que atenderá cualquier 
nivel y cantidad de solicitudes. 

3. En caso de que las solicitudes de trabajo sobrepasen la capacidad de 
los recursos de la instalación y que, por su importancia, se requiera variar 
la prioridad de trabajos ya asignados, es vital que esto sea en forma excep- 
cional, ya que si ocurre con frecuencia sólo se logrará dejar trabajos a 
medias, desanimando en forma constante a los técnicos. Lo más sano sería 
no adquirir nuevos compromisos, a menos que sean de vital importancia 
y en estos casos deberán ser compromisos a corto plazo que permitan con- 
tinuar rápidamente con los proyectos suspendidos. 

4. Para el caso anterior, una opción prudente es solicitar apoyo de 
asesores externos, preparados para cubrir las características de un pro- 
yecto urgente, que aunque se considere costoso, no es así; lo siguiente 
lo confirma: 


a) La garantía de que los productos serán entregados es muy elevada, 
puesto que normalmente el pago de servicios se efectúa a ha entrega 
de los resultados. 

b) Los técnicos de la instalación no se verán afectados. 

e) No se requiere contratar más personal, pues esto, a la larga, resulta 
ne Eo por las implicaciones que representa una contratación 

formal. 


5. Otro factor importante y que con frecuencia pasa inadvertido es 
que habrá que considerar las cargas de trabajo que generan con nuevos 
trabajos en producción. Antes de aceptar un nuevo compromiso será 
necesario medir los recursos de cómputo que absorberá, porque podría 
aumentar la configuración del equipo. Si esto no se visualiza claramente 
puede crear atrasos y trastornos en la producción actual. 

6. Por último se debe evitar hasta donde sea posible, presentaciones 
con el fin de impresionar. Al contrario, debe señalarse la carga de trabajo 
real que representó, y las presentaciones deben ser productivas con una 
tendencia de servicio, pero no por única vez. 


RESUMEN DEL CAPÍTULO 3 


Los directivos que imponen la requisición de trabajos son aquellos a 
los que se les ha trasmitido una idea desvirtuada sobre la capacidad real de 
los equipos de cómputo, así como sus limitaciones; y por lo general no 
entienden la complejidad técnica que requiere este tipo de solicitudes. 
Con frecuencia creen que las computadoras son equipos automáticos que 
generan fácilmente lo que se les solicita. Esto no es responsabilidad de 
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ellos, sino de lo que les han fomentado jefes irresponsables, quienes cuan- 
do tienen oportunidad ofrecen presentaciones con el único fin de cuidar 
<u imagen. Jamás comentan lo complejo que resultó preparar dicha pre- 
sentación, al contrario, aparentan que se realizó en forma simple y rápida, 
Es labor de todo jefe sensibilizar a los directivos, orientarlos para que com- 
prendan la labor y las implicaciones de un centro de cómputo. Deben 
informar a los directivos sobre los proyecto en los que se trabaja y la dispo- 
nibilidad real en cuanto a recursos técnicos y humanos para evaluar la 
posibilidad de absorber más compromisos, En caso de que las solicitudes 
de trabajo sobrepasen la capacidad de los recursos disponibles, es obliga- 
ción del jefe demostrárselo a los directivos y posiblemente, si la situación 
lo requiere, auxiliarse con asesores externos. Jamás debe ocultarse la 
situación real de la instalación, ni hacer presentaciones para impresionar; 
al contrario, debe indicarse lo complejo que resultó, a fin de que si existen 
presentaciones que impliquen cualquier tipo de esfuerzo, éste resulte 
provechoso. 
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Beneficios de la 
asignación equilibrada 
de las órdenes de 
trabajo 


Problema 


Casi siempre hay saturación de trabajo 
por falta de control efectivo, razón por la 
cual dificilmente se desarrollan trabajos de 
investigación, necesarios para un mejor 
aprovechamiento de los recursos de cómpu 


El problema tiene básicamente tres razones de fondo: en unos casos 
se debe al tipo de organización del área de informáti 
do que cuando existen grupos de especialización por proyecto, algunos 
están saturados de trabajo, mientras que en otros hay poca actividad; hay 
casos en los que el problema existe por la adquisición frecuente de com- 
promisos urgentes; y por último, debido a la falta de control efectivo en la 
asignación de trabajos. 


SUGERENCIAS DE SOLUCIÓN 


1. Dentro del esquema informático, las organizaciones están dadas en 
función del tipo de trabajo en el cual se encuentra enmarcado el servicio 
que presta la compañía o institución. Las organizaciones establecidas por 
reas de especialización son más productivas en el campo científico y de 
investigación, en donde cada proyecto lleva, por lo general, varios años 
para su realización; sin embargo, en el terreno comercial, los proyectos no 
duran más allá de algunos meses. Por lo tanto, no es conveniente designar 
un área completa para su desarrollo y posterior mantenimiento, porque es 
así como se produce la falta de equilibrio en las cargas de trabajo. Por esto, 
la estrategia idónea es tener los llamados grupos de servicio, en los cuales 
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tanto programadores como analistas desarrollan de manera indistinta 
cualquier tipo de sistema comercial, para convertirse así en mecanismos 
generadores de sistemas completos y bien documentados; puestos en ope- 
ración, se desligan para atender otros compromisos. 

Es conveniente destacar que una buena documentación es la herra- 
mienta básica que hace operable cualquier sistema, aun por personas ajenas 
a su desarrollo. Debe notarse que cuando no existe documentación, o ésta 
es deficiente, se origina una tendencia muy alta de especialización del per- 
Sonal, propiciando sistemas demasiado peligrosos en su operación y mante- 
nimiento, además de convertira la instalación en un centro de emergencias 
y sobresaltos constantes, lo que obliga a mantener al personal en estado de 
Alerta permanente. 

Cualquier problema en la operación, o cambio en el sistema, produce 
una carga de trabajo severa cuando el personal que la atiende ya está asig- 
nado a otro proyecto. Es de esperar que esta carga de trabajo llevará 
mucho más tiempo, por la falta de documentación. En cambio, cuando 
los sistemas se desarrollan con base en una metodología eficiente, difícil- 
mente fallan en su operación; y si por excepción sucede esto, por lo gene- 
ral son detalles que requieren poco tiempo para su solución, Ahora bien 
cuando para casos específicos se requieren cambios necesarios, donde se 
cuente con todos los antecedentes documentados, es factible que cual- 
quier analista o programador experimentado logre el cambio sin mayores 
complicaciones. No aceptar esto, es como desear que no exista rotación 
de personal y que los especialistas del proyecto permanezcan siempre en 
la instalación. Por el contrario, en instalaciones sin orden es donde más 
rotación de personal existe. 

2, En los casos en que los compromisos urgentes son tan frecuentes 
que rebasan la capacidad de producción del personal técnico, la sugeren- 
cia más recomendable es hacer un llamado de atención al jefe que origina 
esto, pues lo más seguro es que no tenga idea del tipo de trabajo que ahí se 
realiza, o que no sepa concientizar a los directivos de lo que está sucedien= 
do. No se pretende que exista una rebelión mal intencionada sino, por el 
contrario, que la instalación sea estable y que beneficie a sus integrantes y 
principalmente a la compañía, al prestarle un servicio eficiente de infor- 
mación; no debe incurrirse en el error de hacer trabajos al vapor, no docu- 
mentados, con riesgos y mucho menos en un ambiente de descontento 
gencral del personal que origine renuncias frecuentes o en masa. 

3. La falta de control efectivo en la asignación de trabajos se da 
fundamentalmente por falta de metodologías que hagan posible la 
ejecución de trabajos eficientes y que, de acuerdo con cada una de las 
fases de la metodología, permitan medir el grado de avance de cada 
Proyecto, así como la capacidad real de producción. Como ejemplo 
podemos citar el siguiente caso: 
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“Todo programa, para su elaboración, requiere pasar por las siguientes 
fases estándar: 


« Asignación al nivel de programador idóneo para desarrollar el pro- 
grama en función de su complejidad. 

« Estudio de la definición del programa. 

+ Elaboración del diagrama de bloque. 

« Prueba de escritorio sobre el diagrama de bloque. 

+ Codificación en el lenguaje de programación. 

«+ Prueba de escritorio sobre la codificación. 

e Transcripción a medios procesables del computador. 

+ Elaboración de datos prueba en el medio a probar. 

+ Compilación y depuración de errores. 

e Catalogación. 

+ Prueba del programa. 

e Verificación de resultados. 

+ Ajustes de programa si son necesarios. 

+ Documentación y entrega. 


Para esto, si el jefe de programación tiene registrado en un pizarrón 
magnético el nombre de cada programador, así como las fases para la ela- 
boración de cada programa asignado; y en pequeños cartoncillos la clave 
de cada programa, éstos podrán colocarse en la fase correspondiente. De 
un solo vistazo es posible distinguir la asignación individual y el avance de 
cada programa. Ésto, aparte dial jefe de programación pedir 
información de avance y asignación cada vez que lo requiera, le permite 
visualizar la carga de trabajo real en su área de acción, y así considerar si 
aceptará más compromisos, si acaso se los solicitaran. Para esto, deberá 
asignarse a alguien para que pase diariamente con cada programador a fin 
de conocer la fase en que se encuentran los programas y actualice la posi- 
ción de los cartoncillos. 

Un método similar deberá establecerse para las áreas de análisis, dise- 
ño, operación o cualquier otra que exista. 

4. Al lograrse una asignación nivelada de cargas de trabajo, es labor de 
todo jefe evitar que exista personal ocioso el cual no tenga asignado algo 
de provecho. Si esto llegara a suceder, es responsabilidad del jefe del área 
asignar trabajos de investigación que sirvan para el desarrollo técnico de 
cada persona y de beneficio para la compañía. 

Estos trabajos pueden ser los siguientes: 


a) Elaboración de rutinas de utilidad que sean de uso común. 
b) Investigación de facilidades poco comunes o desconocidas del sis- 
tema operativo que sean de provecho, para una mejor explotación 
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de los recursos del computador. 

c) Investigación del funcionamiento de instrucciones de programa- 

"ción poco comuneso desconocidas y que resulten de gran poder, 

d) Análisis de problemas que afecten a otras áreas; en otras palabras, 
llevar a cabo auditorías técnicas. 

e) Estudio de algunos procedimientos de control mal definidos que 
ocasionen retrasos 

f) Estudio de los estándares de documentación que permita simplifi- 
car o mejorar la existente, etcétera. 


A fin de aprovechar cualquier experiencia obtenida en las investiga- 
ciones, se sugiere implantar un sistema de comunicación con boletines 
“en los cuales se divulguen dichas experiencias y se haga partícipe a todo el 
personal técnico para escribir artículos de interés y beneficio común para 
toda la instalación. Podrá informarse sobre nuevos nombramientos, fun- 
ciones, cambios de organización, innovaciones técnicas y, en general, 
cualquier tópico de interés que permita una mejor comunicación entre 
todas las áreas. Mediante esta estrategia, se atacará uno de los problemas 
más graves de toda instalación: la falta de comunicación 


¿ Para cuándo dijo que lo quería ?/ 


La falta de planeación produce incertidumbre en las fechas de terminación. 
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La saturación de trabajo en un centro de cómputo se da básicamente 
por tres razones, a saber: cuando existen grupos de especialización, mien- 
tras unos están saturados, otros están inactivos; cuando se adquieren con 
frecuencia trabajos urgentes; y por último, cuando no hay control efecti- 
vo en la planeación y asignación de trabajos. Las áreas de especialización 
son más productivas en un ambiente científico o de investigación en don- 
de un proyecto generalmente lleva años para su realización. En el terreno 
comercial los trabajos no duran más allá de algunos meses, por lo que no 
hay razón para asignar áreas completas para su desarrollo, La estrategia 
más recomendable es formar los llamados grupos de servicio. En caso de 
que los trabajos urgentes se den con frecuencia, será necesario poner un 
alto al jefe que lo acepte. El desorden en la asignación de trabajos que ori- 
gina desequilibrio en las cargas de trabajo se puede subsanar mediante 
metodologías de control que permitan en todo momento conocer la capa- 
cidad real de producción de cada área. 


Estrategias de 
capacitación 


Problema 


Los técnicos aprenden sobre la marcha, 
de una manera empirica y sin planes de 
capacitación previamente definidos. Muchos de 
olos por iniciativa propia se inscriben en 
escuelas técnicas, costeando sus propios estudios. 


Este fenómeno se presenta en bastantes instalaciones, aunque en 
muchas otras si se siguen planes de capacitación; sin embargo, en algunas 
de éstas, tales planes no son congruentes con las necesidades técnicas que 
existen. En otras palabras, existe la capacitación por el sólo hecho de capa- 
citar. Son pocos los jefes que comprenden que en un centro de cómputo 
las actividades no deben ser empíricas, sino que dado el tipo de trabajo, se 
requiere de especialistas bien capacitados y experimentados que aporten 
un nivel de servicio elevado. Es necesario que los directivos adviertan 
que la inversión de un centro de cómputo no radica únicamente en la 
adquisición del equipo, sino que aún habrá de invertir cantidades, qui- 
zá mayores en capacitación, y que ésta deberá ser permanente. No bas- 
ta con la contratación de personal preparado, pues si éste no es capaci- 
tado en forma permanente, con el paso del tiempo se volverá obsoleto. 
Algunos problemas que origina la falta de capacitación se mencionan a 
continuación 

En primer lugar, los técnicos quedan estancados en cuanto a sus conoci- 
mientos. Al existir este estancamiento la explotación de los recursos de 
cómputo es totalmente deficiente, pues en la mayoría de los casos las labores 
de anali jo, programación, operación y mantenimiento de software 
<on as olgolees que Kapidan svalkar bajos de Ine ráldad.capido 
como resultado un mal servicio para los usuarios; pero la consecuenci 
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grave es la distorsión de las funciones del centro de cómputo. 

Así, al no haber capacitación permanente, el personal técnico deci- 
de abandonar la compañía en busca de nuevos horizontes y mayor opor- 
tunidad de desarrollo, para originar entonces una mayor rotación de 
personal, inflación de sueldos, escasez de personal calificado y peor aún, 
el desquiciamiento de la estructura organizacional y de servicio del cen- 
tro de cómputo. 


SUGERENCIAS DE SOLUCIÓN 


1. Al establecer los planes de capacitación, éstos deben tener un obje- 
tivo concreto y costeable; es decir, los cursos que se programen deben 
estar orientados a fortalecer proyectos en desarrollo y a futuro, pues la 
capacitación no sólo debe capacitar sino estar plenamente justificada. 

2. Es recomendable que existan dos tipos de planes de capacitación: 
externos e internos; es decir, cuando se origina la necesidad de tomar cur- 
sos fuera de la compañía, incluso en el extranjero, se debe enviar a una o 
dos personas, como máximo, plenamente facultadas para aprovechar los 
conocimientos, y ellos serán quienes capaciten al personal restante, Con 
esto se consigue lo siguiente: 


+ Una inversión moderada. 

» Difusión de conocimientos y desarrollo general. 

e Creación de instructores propios de la compañía. 

+ Capacitación permanente y motivación general del personal. 

+ El personal que se envíe a los cursos y que después los imparta, se 
sentirá motivado, reconocido y comprometido moralmente con la 
compañía. 

+ Al existir los cursos internos se crea un ambiente de trabajo sano y 
por consecuencia atractivo para el personal de nuevo ingreso. 

+ Con esto se eliminan envidias y competencias internas malintencio- 
nadas, lo cual permite que se trabaje en confianza dentro de un 
ambiente de compañerismo y colaboración mutua. 
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La capacitación técnica para el personal del centro de cómputo debe 
ser obligatoria. Los planes de capacitación serán congruentes con la filo- 
sofía de los proyectos de la instalación; es decir, la capacitación deberá ser 
por objetivos. Es necesario convencer a los directivos de que la inversión 
de un centro de cómputo no está únicamente en el equipo de cómputo. 
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No basta con contratar personal capacitado al cual no se siga desarrollan- 
do, pues esto con el tiempo los volverá obsoletos. Es recomendable que 
existan dos tipos de planes de capacitación: el primero será la capacita- 
ón externa fuera de la empresa, a cuyos cursos sólo irán una o dos perso- 
e como máximo; el segundo es la capacitación interna que impartirán 
entro de la empresa aquellos que hayan asistido a cursos externos. La 
Capacitación deberá ser permanente y no necesariamente costosa. 


Formación y 
contratación de 
personal técnico 


Problema 


Existe una gran escasez de personal 
preparado y la mayoría de las empresas na 
pueden contratar al personal suficiente. 


El fondo de este problema es bien conocid simplemente no existe 
todo el personal capacitado que se requiere en el ámbito informático. E, 
los últimos años los centros de cómputo y nuestras escuelas, institutos y 
universidades, no han preparado suficientes especialistas en la materia, 
pues no se tomó en cuenta que esta tecnología se expandería con tal rapi 
dez; hace apenas unos años se crearon carreras en materia de informática, 
debido a la gran demanda de este tipo de personal 

Aun así, el personal egresado dista mucho de tener una preparación 
acorde con las demandas del mercado; los maestros que imparten las dife- 
rentes materias de este ramo no cuentan, en su mayoría, con los recursos 
materiales necesarios para preparar verdaderos profesionales; hacen falta 
laboratorios diseñados ex profeso para la capacitación del alumno. 


SUGERENCIAS DE SOLUCIÓN 


1. Para estos casos resulta más seguro y económico capacitar profesio- 
nales recién egresados de carreras de orientación técnica, científica, actua. 
rial, física, matemática o electrónica, incluyendo a los del área de computa. 
ción; y prepararlos exhaustivamente en forma interna y con instructores 
propios de la compañía en cuestión, con lo cual se logra ambientarlos desde 
un principio en la problemática individual de la instalación. Esto sin duda 
es un procedimiento un poco lento, por lo cual, si por la naturaleza de los 
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proyectos debiera ser más rápido, resulta conveniente la contratación de 
Erupos de asesores dedicados a estas labores. p 

2, Si se decide contratar gente con experiencia, hay que considerar 
que las entrevistas superficiales resultan inconvenientes; y como es sab 
do, en este medio existen muchas personas que se dicen “especialistas” y 
Van saltando de una instalación a otra con el único fin de ganar más; como 
*ominan el lenguaje del ambiente de cómputo, impresionan a los entre- 
Vistadores, consiguiendo una contratación rápida. Pero cuando se dan 
cuenta del fraude es demasiado tarde. Por ello es necesario examinarlos 
exhaustivamente en varios sentidos: 


a) Su nivel académico es bueno y sus conocimientos generales acep- 
tables; sin embargo, este tipo de exámenes no deben seguir un for- 
mato predefinido, ya que podría resultar una persona que ha pre- 
sentado muchos de estos exámenes y los conoce muy bien. Lo ideal 
sería que fuera examinado por un comité y en forma oral, con pre- 
guntas recién elaboradas. 

b) Habrá que examinarlo exhaustivamente sobre la especialidad que 
dice tener, pero esto deberá hacerlo otro grupo de especialistas con 
conocimientos actualizados y comprobados en la práctica. Si la 
compañía carece de dichos especialistas, debe pedir apoyo a otras 
instalaciones que sí los tengan. 

e) Se debe distinguir claramente que el candidato tenga varios años 
de experiencia y mo unos cuantos meses, que repetidos en hacer lo 
mismo resultan años. La experiencia se mide por la diversidad de 
proyectos en los que ha aportado sus conocimientos. 

d) Habrá que considerar que el puesto que vaya a ocupar no sea dis- 
tinto a los que ha desempeñado, pues suele suceder que un buen 
analista de sistemas resulta malo como líder de proyecto o jefe de 
un área no acorde con su verdadera capacidad. 


3. Por último, no se debe creer en las recomendaciones verbales de los 
amigos del candidato. Pues es bien sabido que la imagen que se tiene de 
una persona no es la misma para otras, y que los favoritismos no son con- 
venientes en estos casos. 
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Debido al incremento de equipos de cómputo en el país, y a la poca 
Previsión de las autoridades académicas, no existe suficiente personal téc- 
nico en el mercado capaz de satisfacer la demanda, Con verdadera urgen- 


La escasez de personal técnico altamente calificado propicia trabajos de pésima 
calidad. 


ca. Aun así, el personal egresado dista mucho de estar preparado de 
acuerdo con las verdaderas necesidades del medio. Por ello es necesario 
que a los recién egresados se les someta a un buen periodo de capacita- 
ción, después del cual la mayoría resultan buenos elementos. La es 
de este tipo de personal ha favorecido a cientos de charlatanes, los cual 
saltan de una empresa a otra buscando sólo ganar más. Si una empre 
requiere más personal técnico en informática, y el tiempo se lo permite, 
debe contratar recién egresados y capacitarlos. Si la urgencia es verdade- 
ra, debe apoyarse en asesores externos; y si se requiere de especialistas 
propios de la empresa, debe hacerse un plan de contratación riguroso 
para no contratar a un charlatán. 


T 


Ventajas y desventajas 
de la consultoría 
externa 


Problema 


El apoyo de consultores externos para 
resolver proyectos específicos que la 
instalación no puede enfrentar por falta de 
recursos técnicos o falta de experiencia, no 
siempre resulta benéfico. 


En los últimos años se ha extendido la contratación de servicios de 
apoyo para ser realizados por consultores externos; es decir, se contrata 
por un tiempo límite, o por un trabajo específico, a un grupo de especia- 
listas ajenos a la instalación a fin de subsanar rápidamente los problemas 
de trabajo de una determinada área dentro del esquema organizacional de 
un centro de cómputo que lo solicita. 

Si nos referimos en forma concreta a la asesoría externa en materia 
de cómputo, sabemos que ha proliferado el establecimiento de despa- 
chos de consultores, llegando en algunos casos a estar formados por una 
sola persona que, apoyada en una supuesta experiencia, aprovecha 
nuestro deteriorado ambiente de cómputo, el cual ya resiente la impo- 
tencia de afrontar proyectos cada vez más necesarios y ambiciosos en 
esta materia. 

La falta de grupos técnicos integrados y preparados sistemáticamente, 
acordes a las necesidades crecientes que los reclaman, hace que cada vez 
con mayor frecuencia los responsables asignados para la solución de tales 
proyectos requieran apoyo de recursos humanos adicionales, ya sea pro- 
pios o externos a la compañía o institución, y como es de esperar, en la 
mayoría de los casos dichos recursos no están disponibles en la propia 
compañía, razón por la cual optan por contratar los servicios de asesores 
externos. Pero, ¿realmente resuelven así el problema? Las experiencias 
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han demostrado que no siempre resulta exitosa la estrategia; es más, en 
muchos casos resulta tan errado este plan que no sólo no se llega a una 
solución favorable sino que a veces, el ambiente anterior, ya deteriorado, 
empeora aún más, llegando en algunos casos a suspender los servicios ya 
contratados, con la consiguiente pérdida de tiempo invertido y, obvia- 
mente, con el obligado gasto involucrado para luego regresar a establecer 
un plan de restauración del ambiente anterior. 

Tal vez el lector piense que se exagera un poco, pero no es así, yo en lo. 
personal he sido protagonista de múltiples revisiones de contratos de servi- 
cios de consultoría, y me he percatado de situaciones que, de no haberlas 
vivido, ni yo mismo las creería. Voy a referirme en particular a dos casos 
que llamaron fuertemente mi atención por el gran despilfarro en tiempo y 
en dinero que ocasionaron, aunque, por supuesto, no mencionaré el lugar 
ni a los responsables porque no es el objetivo ni está dentro de mi ética pro- 
fesional. 

El primero de ellos ocurrió hace aproximadamente 3 años, entonces 
se tenía contratados a unos 60 técnicos propios de la compañía y el pro- 
yecto consistía en diseñar e implantar un sistema apoyado en un banco 
de datos que diera como resultado una cuenta única para los clientes de 
dicha compañía. Pues bien, por razones que siempre ignoré, para tal 
proyecto se contrató a un grupo externo de 30 especialistas que “trabaja- 
ron” durante año y medio para lograr sólo un raquítico sistema de con- 
sulta trivial que nunca llegó a ser la esperada cuenta única, pero no sólo 
ocurrió eso sino que los controles administrativos de todo el mecanismo 
sufrieron un deterioro imposible de restablecer en menos de un año. 

Los procedimientos rudimentarios anteriores, si bien no lograron la 
cuenta única, sí estaban bajo control y eran conocidos, pero fueron aban- 
donados para que al final de cuentas no se tuviera ni uno ni otro. Cabe 
mencionar que los 60 técnicos propios de la compañía participaron cuan- 
do mucho en un 5% a lo largo del proyecto, pero eso sí, cobraron como si 
hubieran trabajado el 100%. Olvidaba decir que el equipo de cómputo 
con una configuración bastante considerable fue adquirido exclusiva- 
mente para este proyecto, es decir, orientado sólo para dar servicio a un 
solo sistema. Si a esto agregamos los costos del local, dispositivos magnéti- 
cos para el computador, mobiliario, líneas de trasmisión de datos, etc., es 
posible imaginar el costo total del fallido proyecto. Sin embargo, falta aña- 
dir el costo por servicios de los consultores externos, del cual desconozco 
el monto total. Por el conocimiento que adquirí durante mis análisis, esti- 
mo que este proyecto se hubiera logrado, en su totalidad, en un plazo no 
mayor de año y medio y con un costo menor a la mitad de lo que represen- 
tó, si se hubiera ido en forma correcta. 

El segundo caso al que me voy a referir no llegó más allá de la concep- 
tualización equivocada (porque a nadie convenció) de un sistema de con- 
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trol Financiero, en el cual participaron unos 20 especialistas durante 8 
meses, aproximadamente, para concluir en la cancelación del proyecto. 
No conozco la cantidad que costó este intento de proyecto, pero lo que sí 
«do afirmar es que el gasto que se hizo alcanzó miles de dólares. 
Los anteriores constituyen sólo 2 casos conocidos por mí, aunque, 
obviamente, como éstos existen muchos. Si al margen de estas situacio- 
nes pusiéramos una línea divisoria imaginaria, del otro lado encontra- 
Tíamos excelentes trabajos, desarrollados por grupos de consultores o 
asesores externos que no sólo han resuelto múltiples problemas sino 
¿ue han abatido costos en beneficio de las compañías, donde han dise- 
ado e implantado sistemas en tiempos récord y definido estándares de 
trabajo y técnicas de control que hacen a los técnicos de la instalación 
verdaderamente productivos. Han implantado disciplinas creadas y aco- 
pladas a las necesidades particulares de la compañía, y logrado la normali- 
zación continua de los servicios de cómputo hacia los distintos usuarios. 
Han provocado cambios en la mentalidad de los técnicos propios de la 
instalación, eliminando vicios dañinos al propio centro de cómputo, Han 
apoyado fuertemente a altos directivos y conseguido que éstos tomen 
mejores decisiones. Han publicado libros tendientes a difundir su vasta 
experiencia en las variadas disciplinas del ámbito computacional y, en 
general, han enriquecido poco a poco nuestra raquítica tecnología, tanto 
en materia de hardware como en software. 

Aunque se piense que me he apartado del tema, lo anterior fortalecerá 
aún más el contenido que aquí expongo, pues de otra manera sería difícil 
que se pudiera ilustrar en forma real el encabezado de este problema. 

Alo largo de los párrafos anteriores he hablado de lo bueno y lo malo 
con respecto al trabajo de asesores externos (o consultores); como en todo, 
existen trabajos buenos y malos, pero como buen comprador, en la deci- 
sión de adquirir algo bueno, interviene el grado de conocimiento de lo 
que se desea comprar. Habrá más posibilidades de una buena compra si 
existe conocimiento previo del artículo, o en su defecto un cuestiona- 
miento más profundo de la calidad o ventajas que se tendrán al adquirirlo. 
Pues bien, precisamente éste es el análisis que haremos a continuación, 
sólo que en este caso el artículo hará referencia a los servicios de asesoría 
externa en materia de cómputo y lo que haremos será dar una serie de 
orientaciones y argumentos para que el comprador de servicios adquiera 
lo mejor para su provecho. 


pue 


SUGERENCIAS DE SOLUCIÓN 


1. Estudio preliminar para llevar a cabo el proyecto. Una vez que se ha 
convencido a la alta dirección de que dé su aprobación, generalmente se 
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procede a establecer la estrategia según la cual se atacará el proyecto. Es 
aquí donde empiezan los problemas, pues al hacer un análisis más detalla- 
do, que a veces toma varias semanas, o quizá meses, se dan cuenta de que 
para ese momento no cuentan ni con la infraestructura de recursos 
humanos ni con los conocimientos necesarios para el buen logro del com- 
promiso que han adquirido; y como para entonces ya es un trabajo en car- 
tera con límite de tiempo para su terminación, las urgencias principian y 
ya no hay tiempo de preparar a los técnicos de la instalación, por lo que la 
opción más viable es la contratación de asesores externos. 

2. Solicitud de servicios de asesores externos. Es importante que no se 
tome a la ligera este punto, pues en muchas ocasiones se contrata a un 
grupo de asesores teniendo en cuenta únicamente la recomendación 
superficial de algún amigo; considérese que esta etapa puede resultar la 
más crítica para el éxito del proyecto. 

No permita que su proyecto fracase. Atienda las siguientes recomen- 
daciones, las cuales no son empíricas sino que están sustentadas en expe- 
riencias muy valiosas. 


a) Una vez que ha elegido la contratación de asesores externos, con- 
vénzase de que la selección del grupo a contratar le llevará cierto 
tiempo, es decir, no deberá apresurar por ningún motivo esta fase. 

b) Lance una convocatoria en el periódico, donde señale en forma 
concreta los objetivos del proyecto así como los recursos generales 
de hardware y software con que se cuenta, a fin de que acudan al 
llamado sólo aquellos asesores que se sientan competentes para 
realizar dicho proyecto. Con esto se ahorrará tiempo y tendrá la 
certeza de que sólo acudirán asesores interesados en el proyecto. 

c) Haga que cada representante de grupo de asesores sea entrevistado 
por una persona que conozca de integración de personal, para que 
analice la seriedad de la formación del grupo de asesores que ofre- 
cen sus servicios. Una buena estrategia en este momento es formu- 
lar un pequeño cuestionario que el entrevistado firmará al término 
de la entrevista, en el cual se establezcan preguntas que formalicen 
la veracidad de la integración legal y de la estructura del grupo, 
bajo protesta de decir verdad. La persona que lo firme deberá tener 
reconocimiento legal de su grupo. Usted verificará que dicho cues- 
tionario sólo sea firmado por grupos completamente estructura- 
dos. En este momento la selección del grupo será más depurada y 
segura. 

d) Una vez que se cuente con los representantes de los grupos de ase- 
sores perfectamente estructurados, el siguiente paso será cuestio- 
nar si en verdad su estructura organizacional y su experiencia, 
aunada a sus conocimientos, reúnen los requisitos potenciales para 


e) 
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garantizar el éxito del proyecto. Para este caso reúna a los represen- 
tantes y formalice una plática con la duración necesaria para expli- 
carles con detalle los alcances del proyecto, recalcando cada uno de 
los resultados requeridos; adviértales que la terminación del pro- 
yecto se dará con conclusión de cada uno de los resultados expues- 
tos. No permita que se limiten a entregar sólo algunos resultados. 
Debe quedar bien claro que el proyecto se dará a aquel grupo que 
se apegue a las estrictas demandas de la compañía, por lo cual el 
compromiso será adquirido sólo por grupos de asesores plenamen- 
te seguros de que lograrán el proyecto en su totalidad. Esta plática 
deberá darla el personal de la compañía que elaboró el estudio pre- 
liminar para realizar el proyecto; dicha plática deberá terminar 
sólo cuando haya aclarado todas las dudas de los asesores. Si es 
necesario propicie una segunda plática para que los asesores ten- 
gan tiempo de estudiar las notas o apuntes que la misma compañía 
les haya proporcionado y no se dé lugar a malos entendidos, Es 
conveniente formular un cuestionario breve, el cual será firmado 
por cada representante para saber si la plática cumplió con su obje- 
tivo y se despejaron las dudas. Si existen, aclárelas. 

Solicíteles propuestas de estrategias para llevar a cabo el proyecto, 
así como de sus respectivas cotizaciones; y seleccione como máxi- 
mo tres de estas propuestas. Para efectos de este tipo de selección 
tome en cuenta los siguientes aspectos: 


+ Es candidato a selección el grupo que disponga de una diversidad de 
especialistas y que asigne por lo menos a un experto en cada área 
que reclame el proyecto. En otras palabras, será candidato aquel que 
cuente con un mejor grupo de especialistas congruente con la filo- 
sofía del proyecto. 

+ Es candidato a selección el grupo que haya participado anterior- 
mente en proyectos similares y de igual o mayor magnitud. 

+ Es candidato a selección el grupo que tenga como mínimo 3 años de 
establecido y un índice bajo de rotación de personal. 

+ Es candidato a selección el grupo que tenga mayor cartera de clien- 
tes importantes (no de clientes en general). 

+ Es candidato a selección el grupo que tenga oficinas completamente 
establecidas, lo cual demostrará la formalidad de su integración. 
+ Es candidato a selección el grupo que tenga establecido en su con- 
trato menos cláusulas de protección tendientes a abolir su responsa- 

bilidad en el proyecto. 

+ Es candidato a selección el grupo que precise en forma concreta los 
resultados a los que se compromete, y que cumpla con los requeri- 
mientos del proyecto. 
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« Por último, es candidato a selección el grupo que se comprometa 
por escrito al cumplimiento total del proyecto, según les fue reque- 
rido en las pláticas, 


Como se habrá notado, no hemos hablado de costos ni de tiem- 
pos; el objetivo principal de esta selección es garantizar, hasta 
donde sea posible, el éxito del proyecto; es decir, el cumplimiento 
integral del mismo; no se recomienda que se busque lo más barato 
y se desperdicie sin beneficio alguno, o que se ahorren algunas 
semanas, descuidando actividades de importancia que a la postre 
lleve a tareas frecuentes de emergencia, lo cual provoca un estado 
constante de sobresaltos por falta de previsión, obligado por un 
poco más de tiempo. Como quiera que sea, tanto el costo como el 
periodo son negociables y sujetos a acuerdo. Lo que no resulta es 
partir de bases infundadas que pongan en peligro el éxito del pro- 
yecto en su totalidad o parcialmente. No hay razón para permitir 
esto cuando es posible un control estricto y culminar con éxito. 
Una vez seleccionadas 3 propuestas, como máximo, no se apresure 
tomar una decisión, y mucho menos a firmar un contrato, pues 
todavía falta un aspecto de suma importancia: pedir a los grupos 
seleccionados que muestren ejemplos de la documentación de tra- 
bajos similares al que pretenden hacer, Este detalle será la culmina- 
ción con la cual se garantizará, en gran medida, el buen logro del 
proyecto, pues lo que mostrarán, aparte de confirmar su participa- 
ción en trabajos similares, será la calidad, orden y magnitud de lo 
que saben hacer. Finalmente, usted se convencerá de qué grupo 
representa su mejor adquisición de compra de servicios. Pues en 
este momento aprendió a conocerlos, supo de su trayectoria, esti- 
mó la garantía que representaban para el buen fin del trabajo que 
desarrollarán y que tuvo una muestra de sus habilidades. 
Prepárese a firmar un contrato. En este momento usted ya debió 
haber colocado las propuestas y determinado primera, segunda y 
tercera opción. Es el momento de negociar las cotizaciones y los 
periodos; es decir, no debe aceptar estos dos aspectos a la primera 
vista de las propuestas. Pida a cada representante que le sea justifi- 
cado tanto el costo como el tiempo, y una vez que se ha llegado a un 
acuerdo, comunique su decisión a los grupos candidatos haciéndo- 
les ver que basó su decisión en los elementos que ellos mismos die- 
ron. Este pequeño detalle comprometerá moralmente al grupo 
seleccionado; y a los no seleccionados les hará sentir la importancia 
que se les dio a sus propuestas, colocándolo a usted como un hom- 
bre honesto, metódico y sobre todo, imparcial. Pues bien, lo que la 
mayoría de la gente haría en este momente sería pedir al grupo 
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seleccionado que redacte su contrato y lo presente para revisión y 
autorización. ¡Pues no!, el contrato deberá ser redactado en con- 
junto para evitar correcciones futuras; y lo más importante, recal- 
Mar por último los compromisos adquiridos, sin dejar ningún cabo 
Saeko, ya que podría existir la posibilidad de un posterior malen- 
tendido mutuo. 


3. Firma del contrato. Si usted siguió en forma sistemática los pun- 
tos anteriores, e incluso otros propuestos por su misma compañía, firme 
ton toda confianza, libre de temores, convencido de que ha puesto bases 
muy sólidas para el buen éxito del proyecto. Además, siéntase satisfecho 
de cuidar los intereses de la compañía que le facilita el sustento personal 
f cambio de su excelente trabajo. Si descuidó estos factores, prepárese a 
enfrentar uno de los más Fuertes fracasos personales, y posiblemente 
hasta la pérdida de su trabajo. Todo esto por falta de cuidado, o peor 
aún, por falta de conocimientos. 

4, Inicio del proyecto. Si bien ya se han establecido bases sólidas al 
contratar al grupo idóneo para lograr resultados exitosos, no dejan de ser 
sólo eso. Hay que entender que faltará el verdadero trabajo, ie lecer 
realidad los planteamientos teóricos. En ocasiones se piensa que al 
haber contratado a un buen grupo de asesores, de ahí en adelante sólo es 
problema de ellos lograr el proyecto. ¡Pues no! Aunque si bien ellos 
harán el trabajo, deberá ìr un lider del proyecto propio de la compa- 
ñía, y él es quien deberá establecer los estándares y políticas de trabajo a 
que se deberán sujetar cada uno de los asesores que trabajen en el pro- 
yecto. En otras palabras, el control del proyecto estará siempre en manos 
del personal de la compañía y nunca deberán permitirse abusos por par- 
te de los asesores. No hay que olvidar que el control del negocio siempre 
deberá estar en manos del dueño y no de los empleados, de otra manera 
se va a la quiebra. 

5. Desarrollo del proyecto. Es conveniente, casi indispensable, que se 
administre el avance del proyecto bajo la filosofía de productos termina- 
dos; es decir, a la terminación de cada actividad, ésta deberá arrojar un 
producto completo que demuestre en forma tangible que dicha actividad 
ha sido cubierta formalmente. De lo contrario, se dan por terminadas 
actividades que aún no lo están, sólo porque alguien lo afirma así, y son 
registradas como terminadas cuando ni siquiera hay indicios de ello. 
Recuérde que las riendas de control las lleva el propio personal de la com- 
ia; por lo tanto, ellos deberán dictar los procedimientos más conve- 
nientes para, incluso, dirigir el avance de las propias actividades de los 
asesores, y no perder en ningún momento la dirección correcta hacia la 
terminación exitosa de la actividad. 

6. Terminación del proyecto. Es de vital importancia detectar cuándo 


54 CAP. 7. VENTAJAS Y DESVENTAJAS DE LA. 


en realidad el proyecto ha sido concluido en su parte técnica; para esto, 
aparte de la administración por medio de productos terminados, se cuen- 
ta con el contrato en el cual están especificados los resultados concretos 
comprometidos, y obviamente esto estará amparado por demostraciones 
prácticas de cada resultado, donde se requiera de los asesores un plan de 
prueba integral que contemple hasta los más mínimos detalles respecto al 
alcance del proyecto. Si fuera necesario tómese varios días, pero no se 
arriesgue a aceptarlo sobre pruebas superficiales. 

7. Implantación y liberación del proyecto. A este respecto, algunas 
compañías concluyen su contrato con los asesores al término de las prue- 
bas y presentaciones de cada producto; pero olvidan que la actividad que 
determina el éxito verdadero de un proyecto es cuando los usuarios ope- 
ran fluidamente los resultados del sistema computarizado, del cual a 
veces resulta igual o más compleja su implantación que su desarrollo. Por 
lo tanto, pensar así es un grave error, que puede obstaculizar y opacar en 
gran medida todo el esfuerzo. Por tal razón, el contrato debe contener este 
servicio de vital importancia, y no se dará por terminado el compromiso 
hasta ver completamente en operación formal el sistema logrado. 

8. Recepción del proyecto. A propósito no he mencionado la partici- 
pación que debe tener el personal técnico que labora en la compas 
He querido dejarlo hasta el final por considerar este momento el más 
oportuno para analizar su impacto. Pensemos que todo el trabajo de 
detalle lo han hecho los asesores, por lo tanto, la experiencia integral y el 
conocimiento profundo será de ellos; pero, ¿qué va a suceder cuando los 
asesores se retiren de la compañía?, ¿quién va a dar mantenimiento al 
sistema?, ¿quién podrá dar un dictamen correcto y rápido cuando se 
presente Min problema operativo?, ¿quién podrá hacer modificacio- 
nes para nuevos resultados solicitados?, podríamos seguir cuestionando 
hasta comprender que éste es el peor procedimiento cuando se solicita 
servicio de asesores externos. Es muy importante que participen activa- 
mente algunos técnicos propios de la compañía, cuyo trabajo consista en 
empaparse de los más míninos detalles y pormenores del sistema que 
luego heredarán. Una buena estrategia para lograr esto es asignarles la 
tarea de documentar, con lo cual se verán obligados a enterarse de todo 
cuanto tenga que ver con dicho sistema; de esta manera, el proceso de 
recepción del proyecto será a conciencia y menos lento, garantizando 
así la operatividad y el mantenimiento del proyecto. 

Creo que ahora sí tenemos más elementos de juicio para aventurar un 
dictamen más certero; y digo aventurar porque quien decida de qué lado 
debe inclinarse la balanza será el responsable de contratar asesoría exter- 
na. La manera como intuya que debe dirigirla es la que, con el tiempo, le 
dirá si su decisión fue buena o mala, porque hasta para contratar asesoría 
externa se debe estar preparado; sí no, los resultados son desastrosos. 
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Para terminar, desde mi punto de vista la asesoría externa es una 
opción excelente cuando se sabe dirigir; note usted algunos de sus benefi- 
cios inmediatos: 


+ Se resuelve un problema a corto plazo, ya que se compran conoci- 
mientos y experiencia en forma inmediata. 

+ La garantía de que los productos se entregarán es elevada, si se nego- 
cia que el pago sea a la terminación de los productos, con seguridad 
éstos se terminarán por completo. 

+ Los técnicos de la instalación, en su mayoría, no se verán afectados 
en sus proyectos vigentes. 

+ No se requerirá contratar más personal, pues esto a la larga resulta 
más caro por las implicaciones que se adquieren al hacer una con- 
tratación formal. 

+ El pago de la asesoría externa es por única vez y no de por vida, 
como en el caso de los empleados propios. 


La asesoría externa es la peor opción si no se está preparado o no se 
sabe cómo dirigirla. Por lo tanto: 


La asesoría externa: ¿ventaja o desventaja? 


¡Usted dirá! 
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Cuando algún proyecto resulte de tal magnitud que no pueda ser 
cubierto por personal técnico de la propia compañía, quizá piense en con- 
tratar los servicios de asesores externos. Si.es así, no lo haga a la ligera, pre- 
párese a conciencia y siga un método que le garantice que la opción será 
exitosa. Haga una selección metódica a fin de elegir al grupo más prepara- 
do para resolver el problema. Usted será el director del proyecto, nunca 
permita que los asesores hagan lo que más les convenga. Dirija el proyecto 
hacia el éxito y marque a los asesores el camino a seguir; haga que trabajen 
pero bajo el método que a usted convenga. Nunca deje el negocio en 
manos de los empleados porque irá al fracaso. A usted es a quien interesan 
los buenos resultados, no suelte las riendas ni permita que se pierda tiem- 
po inútilmente. Dé la dimensión perfecta a la terminación de cada activi 
dad y no lo dé por hecho cuando no exista un producto tangible. Com- 
pruebe que los resultados del trabajo son cabalmente cubiertos mediante 
pruebas y demostraciones exhaustivas y no con revisiones superficiales, 
Apruebe el proyecto cuando esté en operación y no cuando le hayan mos- 
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trado sólo algunas pruebas. Integre personal propio de la empresa desde el 
principio del proyecto, para así no depender indefinidamente de los ase- 
sores. La asesoría externa es una opción excelente cuando realmente se 
sabe dirigir; y es la peor opción si no se está preparado o no se sabe cómo. 
dirigirla. La asesoría externa, ¿ventaja o desventaja?, eso lo contestará 
usted según su punto de vista y experiencia. 


La importancia de la 
participación de los 
usuarios 


Problema 


Los usuarios de la Información están 
frecuentemente insatisfechos por la falta de 
un nivel de servicio acorde a sus necesidades 
reales; y en algunos casos tienen un total 
distanciamiento del centro de cómputo, 


Esta situación se genera básicamente por una falta de comi 
muy grande, pues con frecuencia se olvida que los usuarios juey 
el papel más importante dentro de los objetivos específicos de todo centro 
de cómputo, ya que son ellos en esencia quienes hacen uso efectivo de la 
información producto de los procesos del computador, y quienes real- 
mente pueden evaluar la verdadera utilidad de dicha información; sin 
embargo, casi siempre se les aisla y se les obliga a depender de lo que a jui- 
cio de los técnicos debe considerarse dentro de los diseños de sistemas, 
razón por la cual, en muchas situaciones, los usuarios manifiestan su 
inconformidad, puesto que los resultados de los sistemas no alcanzan a 
cubrir sus necesidades de información, que a su vez les permitan hacer 
fluido su trabajo operativo. 


SUGERENCIAS DE SOLUCIÓN 


1, Es de vital importancia para todo diseño de sistemas hacer partici- 
pesa los usuarios, de manera que se sientan parte integrante de un mismo 
equipo de trabajo, y que el éxito de los sistemas de información depende 
en gran medida de su participación activa, pues son ellos quienes real- 
mente viven la problemática de la falta de información; por lo tanto, son 
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ellos la fuente fundamental que dará la pauta a los sistemas a diseñar. No 
basta con solicitarles datos acerca de los problemas a resolver, sino pedir- 
les sus puntos de vista, sobre cómo, a juicio de ellos, se podría resolver; 
hacerles sentir además, que participan desde el análisis y el diseño. De la 
misma forma, se debe revisar junto con ellos cada uno de los resultados a 
obtener, así como la utilización provechosa que se hará de los mismos; por 
ningún motivo se les hará sentir que se les están imponiend 

Mediante esta estrategia ellos sentirán que en parte también son res- 
ponsables de lo que se logre con el sistema y en consecuencia, siempre 
estarán dispuestos a colaborar de común acuerdo y difícilmente habrá 
fricciones. Lejos de eso, la relación será más estrecha en un ambiente pro- 
fesional y de participación conjunta. Con esto se fomentará una realidad 
ana, pero poco aceptada. El centro de cómputo y los técnicos son ele- 
mentos de apoyo y de servicio, mas no “dictadores de órdenes”. 

2. A fin de que exista un entendimiento más efectivo y una comuni 
cación más estrecha, es necesario que el personal técnico organice semi- 
narios sobre procesamiento de datos para todos los niveles de usuarios 
de la información, en los cuales se den a conocer los conceptos más ele- 
mentales, pero necesarios, para que comprendan con facilidad los tecni- 
cismos más usuales del ambiente y no se sientan cohibidos cuando éstos 
son mencionados. Pues cuando un técnico entrevista a un usuario y 
comienza a mencionar tecnicismos que éste no entiende, automática- 
mente se crea una barrera que vuelve tediosa la entrevista; a consecuen- 
cia de esto, el usuario ya no quiere participar y entonces nace el recelo 
de uno hacia otro. 

3. Como un filosofía que todos los técnicos deben establecer para 
toda entrevista con usuarios, se sugieren los siguientes puntos: 


+ Documentarse sobre las características y funciones del entrevistado, 
siendo esto útil para entrar en confianza. 

+ Destacar la importancia de la intervención del entrevistado en el 
desarrollo del proyecto a implantar, para lograr su apoyo. 

+ Dirigir la entrevista para que el entrevistado plantee las soluciones 
al sistema, con objeto de que lo sienta como creación suya. 

+ Hablar con tacto, sin herir susceptibilidades ni criticar. 

+ Saber escuchar, pero sin dejar de tener iniciativa. 

+ Contagiar entusiasmo por el proyecto. 

« Dejar que el entrevistado se explaye sobre sus funciones, para captar 

leas que beneficien al sistema. 

+ No permitir que el entrevistado lo desvie del objetivo básico de la 
entrevista, pero con discreción. 

+ Hablar con seguridad y evitar ser el entrevistado en lugar del entre- 
vistador, sin ser demasiado brusco. 
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+ Toda entrevista provoca situaciones tensas, por ello hay que tener 
seguridad en sí mismo, buena presentación, hablar con claridad, 
no ser irónico, no intimidar con el entrevistado y ser cordial y agra- 
dable. 


4, Por último, es de vital importacia elaborar, antes de la entrevista, 
un cuestionario. Esto dará una imagen de orden y evitará que las pregun- 
tas sean improvisadas. 
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Los sistemas que no ofrecen una solución real y completa a los reque- 
rimientos de los usuarios son aquéllos en los cuales no se consideró a éstos 
y casi les fueron impuestos, Es de vital importancia el hacer partícipes a 
los usuarios desde el análisis de todo sistema, pues son ellos los que real- 
mente conocen sus requerimientos de información. Los usuarios son la 
fuente principal que dará la pauta para los sistemas por diseñar. El éxito 
de un sistema está dado en gran medida por la participación de los usua- 
ios. El centro de cómputo y los técnicos son elementos de apoyo, mas no 
‘dictadores de órdeńñes”. Es necesario impartir seminarios técnicos sobre 
procesamiento de datos, de acuerdo con el nivel requerido por los usua- 
rios, para que éstos conozcan los conceptos fundamentales y puedan par- 
ticipar con más confianza. Durante las entrevistas técnicos-usuarios es 
Fundamental seguir un método y elaborar cuestionarios previos. 


Acercamiento entre 
técnicos y usuarios 


Problema 


Las computadoras electrónicas siguen 
siendo "calas negras” para los usuarios del 
los sistemas de información 


Si nos remontamos un poco a la historia de la computación en México, 
recordaremos que en este país, por vez primera en Latinoamérica, fue creada 
una carrera oficial en ciencias computacionales, gracias al entusiasmo de unas 
cuantas personas que por fortuna comprendieron la trascendencia futura de 
esta tecnología. Esto ocurrió en el año de 1964, cuando tocó a nuestro país 
establecer la carrera de técnico en computación electrónica, cuyo reconoci- 
miento sirvió de plataforma para las carreras profesionales, de maestría e inclu 
so de doctorado que actualmente existen. 

Aún se recuerda en el ambiente computacional de México que la 
asignación de los primeros planes de estudio fueron designados al IPN, 
a través de la escuela tecnológica núm. 3, “Juan de Dios Bátiz". También 
se debe un reconocimiento muy especial a los principales promotores de 
dicha carrera, los cuales participaron como jefes del proyecto y de quie- 
nes se puede decir que abrieron la brecha inicial para que México no 
siguiera a la zaga de esta tecnología. Ellos fueron el C.P. don Luis Sen- 
deros, el C.P. Roberto Bermúdez Limón y el Ing. Emiliano Hernández 
Martínez. 

Fuera de este gran esfuezo, cuyo incalculable valor reconocemos, no 
recordamos ningún otro intento serio en la década de los sesenta que pro- 
moviera a nivel académico oficial esta carrera; y si lo hubo fue tan irrele- 
vante que se perdió en el anonimato. 

Lo anterior refleja por sí solo el grado de atraso tecnológico que 
hemos padecido y seguimos tolerando casi con la misma fuerza o quizá 
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más que en años anteriores. Esto ocurre y seguirá sucediendo mientras no 
nos interese lo suficiente esta tecnología, o peor aún, tal vez sea porque 
aún seguimos sin comprenderla. 

¿Será posible que aún no reconozcamos la enorme importancia que 
representa dicha tecnología para los países desarrollados? Y qué decir de 
aquellos en vías de desarrollo como el nuestro. Decimos esto porque se 
antoja incómodo y denigrante que si las computadoras en Estados Unidos 
y otros países ya eran utilizadas de manera productiva desde finales de los 
cuarenta, apenas 20 años después, timidamente y más influenciados que 
convencidos, se comenzaron a usar en México. 

Esto sólo demuestra nuestro nivel de pasividad y nuestro grado de 
conformismo, aparte de nuestra triste realidad. Habrá que reconocer que 
no ha sido por falta de científicos y estudiosos capaces de lograr incluso 
una tecnología propia, aunque fuera limitada. Más bien, y lo tenemos que 
aceptar, lo que sucede es que existe poco interés por parte de las autorida- 
des para asignarle apoyo y prioridad a esta tecnología. Por desgracia segui- 
mos aceptando la de “fácil aplicación”, sin el doloroso proceso que impli- 
ca el desarrollo de ésta. Por ello tenemos que aceptar lo importado como 
verdad única y absoluta. 

Antes de 1964 no había ninguna carrera universitaria en informática. 
Es más, ni siquiera había proyectos para implantarla. Para programar sis- 
temas de cómputo no se requería personal con preparación universitaria. 

Tampoco hubo tiempo de prepararlo. Así pues, se lanzaron los cursos de 
4 a 6 semanas, tanto de los proveedores de equipo, que tenían obligación 
de ofrecer personal a sus clientes, como de los particulares, sin ninguna 
obligación, pero con ganas de hacer algo. 

De esta manera poco a poco se fue “moldeando” el “fantasma de la 
computación electrónica”, es decir, se comenzaba a fabricar algo intangi- 
ble, raro, y que sólo al mencionarlo era preferible ignorarse, porque desde 
un principio se consideró algo “intocable”. 

Sólo pocos elegidos que tuvieron la fortuna de asistira algunos cursos 
al vapor y que lograron comprender a medias los. conceptos básicos, o sim- 
plemente aprendieron el lenguaje de la computación, eran los que esta- 
ban “autorizados” para trazar el destino informático del país. 

Por eso se crearon los “expertos” de la informática, quienes celosa- 
mente atesoraban sus raquíticos conocimientos de cómputo. De no haber 
sido así, hubiera peligralo su estatus; además se corría el riesgo de que se 
descubriera que la informática no era más compleja que cualquier otra 
materia académica, y mucho menos que fuera infranqueable como los 

expertos” la hacían parecer. En esos tiempos ellos lo hacían todo: diseña- 
ban, programaban e incluso operaban los ficticios sistemas de la época. 
Sencillamente impresionaban. 

Con lograr que la computadora aparentara trabajar, girando cintas, 
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leyendo tarjetas o enviando mensajes, inclusive con error, era suficiente 
para demostrar a los “iletrados” en la materia que ellos eran los únicos 
capaces de entender esos equipos. 

Y qué decir cuando, mediante un pequeño programa obtenían algún 
reporte impreso, que por cierto muchas veces contenía resultados inven- 
tados o inexactos; era lo máximo. Era inconcebible para los espectadores 
la velocidad con que se imprimían dichos reportes (300 o 600 lineas por 
minuto). Por todo lo que eran capaces de hacer los “expertos”, se les con- 
sideraba “sabios”. 

De lo anterior se deduce que sencillamente no había “usuarios” de 
la información; pero cómo iban a existir si no entendían lo que estaba 
ocurriendo o hacía dónde se pretendía llegar. 

La información que los “usuarios” debían manejar, e incluso los pro- 
cedimientos administrativos propios de ésta, siempre les fueron impues- 
tos. Esto no es un secreto. En la actualidad, a 20 años de distancia, sigue 
sucediendo, y todos los que trabajamos en el medio lo sabemos. 

Cuando a principios de los setenta por fin se logra desenmascarar a 
muchos “expertos”, el “fantasma de la computación” se empieza a desva- 
necer. Toman impulso las especialidades de análisis y diseño de sistemas, 
programación y operación; es decir, las cosas se empiezan a tomar más en 
serio y los “expertos” pierden poco a poco su fuerza, pues ya no les es posi 
ble continuar engañando y menospreciando a la nueva generación de 
especialistas, los cuales se encuentran más preparados 

Al haber más conciencia, no de las bondades de las computadoras 

ino de la necesidad del manejo y control de la información, empieza a 
tener sentido desarrollar análisis de necesidades de información, así como 
del diseño de sistemas computarizados. Por fin se piensa en que deben 
existir “usuarios” que puedan aprovechar los resultados de dichos siste- 
mas. 

Sin embargo, los “usuarios”, al continuar desconociendo, ya no el 
potencial verdadero de los equipos de cómputo, sino los conceptos más 
elementales que les permitan “comunicarse” con los analistas de sistemas, 
siguen siendo ignorados, y ahora a expensas de lo que ordene y diga el 
Famoso analista de sistemas. 

Cuando por desesperación o iniciativa personal, algún “usuario”, 
con todo el conocimiento de causa proponía soluciones ingeniosas 
durante el análisis, bastaba con que el analista le lanzará un “conejo” 
para convencerlo de que “eso es imposible de hacer en la computado- 
ra”, y ahí quedaba todo. 

De esta manera, el “usuario” seguía reprimido y aislado. Sólo se le 
tomaba en cuenta para entrevistarlo y obtener sus conocimientos sobre las 
necesidades de la información, para posteriormente imponerle los proce- 
dimientos a seguir, incluso se le entregaban los instructivos para el uso y 
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manejo de la información, bajo consigna de que debía respetarlos porque 
de otra manera podría entorpecer las labores del centro de cómputo. 

Así, aunque frecuentemente no le solucionaban los problemas de fal- 
ta de información al “usuario”, sí le ocasionaban trabajo extra para lograr 
los múltiples ajustes que medianamente subsanaran las graves deficien- 
cias de los sistemas diseñados. 

Sólo reflexionando en lo anterior se puede comprender el recelo que 
se ha fomentado entre los “usuarios” y el centro de cómputo. Esto tampo- 
co es un secreto. 

"Al llegar a los ochenta, se ponen de moda los “paquetes de software”, y 
se dice que ya no son necesarios ni analistas de sistemas ni programado- 
res. Que los paquetes son del tipo “universal”; es decir, que satisfacen casi 
todas las necesidades de información de los “usuarios”. 

La realidad de esto es que ni son “paquetes universales” ni desapare 
cerán analistas ni programadores. La mayoría de los paquetes son tan rígi 
dos que cuando existe la necesidad de algún cambio de tipo legal, o algún 
nuevo requerimiento de información, la respuesta es simple: “no se pue- 
de" o "implica una modificación de alto nivel”, 

Esto lo sabemos todos porque no es un secreto. Sin embargo, el objetivo 
no es criticar los paquetes sino señalar que si antes, por lo menos existían 
entrevistas a los “usuarios” de la información, ahora se dice que ya no es 
necesario. Por lo tanto, al “usuario” se le reprime aún más ignorando por 
completo su opinión y casi se le desaparece del mapa informático. 

Todos los que de alguna manera hemos vivido el desenlace de la 
informática en México sabemos lo anterior y lo aceptamos como un mal 
del ambiente. Nos hemos acostumbrado a admitirlo como una situación 
normal. 

Nos resistimos a reconocer, o no queremos aceptar, que en la ope- 
ración de cualquier sistema manejado por computadora el "usuario" es 
realmente el “cerebro” del análisis de la información, él es quien logra 
que los resultados que se obtengan, producto del diseño, sean los más 
adecuados y congruentes con la verdadera necesidad. Sencillamente 
los “usuarios” son quienes conocen con precisión sus requerimientos 
de información. 

Por otro lado, son ellos la verdadera fuente de información para con- 
cretar sistemas eficientes, que emitan resultados veraces y de calidad, 
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Los recursos de informática (computadora, paquetes, especialistas, 
etc.) sólo son recursos de apoyo al servicio de quienes conocen con exacti- 
tud el problema a resolver, las necesidades de información, la justifica- 
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ción y los riesgos. En sí, la esencia de la verdadera razón de la existencia 
de los centros de cómputo son los “usuarios”. 

En 1984 tomó auge el hecho de poner a disposición de los “usuarios” 
grupos de terminales y paquetes para que ellos mismos operen directa- 
mente su información en la computadora. Esto parece ser la solución 
ideal, al eliminar el cúmulo de intermediarios e imposiciones a que 
hemos hecho referencia. 

Permitirá sin duda acortar la línea de comunicación entre el “usua- 
rio” y la computadora, y quizá al aunar los recursos de cómputo, creativi- 
dad y la experiencia del propio “usuario” en la problemática y manejo de 
la información, se logren verdaderos sistemas de información, acordes 
con las necesidades existentes. 

Pero no nos engañemos otra vez al idealizar una solución que 
requiere preparar el terreno, que no puede suceder sólo porque así lo 
deseamos. Seamos realistas, esto demanda una estrategia lógica de pasos 
naturales, como cualquier programa de computadora. Recordemos que 
la computadora siempre se le ha presentado al “usuario” como una “caja 
negra” 

Imaginemos que nosotros, “los informáticos”, sabemos que la “caja 
negra” contiene un león en su interior. Ahora se le dice al “usuario” que 
se acerque sin temor a la “caja negra” (al león), pero sólo se lo pedimos, es 
decir, no lo preparamos. El “usuario” confía en nosotros y se acerca; 
entonces el león se lo come, pero no es eso lo que queremos. 

Por lógica, el primer paso que se debe dar es hacer que el “usuario” y 
el león se conozcan y se conviertan en amigos. De lo contrario, el león 
sentirá que el “usuario” lo quiere agredir; aunque éste simplemente desea 
acercarse, el león lo atacar: 

Para evitar esto existen dos opciones inmediatas. La menos prudente 
consiste en amaestrar al león para que no ataque. Sin embargo, nunca se 
puede saber cuando el léon va a enloquecer y atacar. La segunda es más 
sensata: capacitar al “usuario” para que sepa con certeza cuándo el león 
tiene intenciones de atacar y se le den armas y recursos para que, aunque 
el león (amaestrado o no) ataque, el “usuario” siempre resulte ileso. 

De esta manera, por instinto natural, el león se rendirá y preferirá ser 
amigo del “usuario”. Lo importante es que éste estará preparado. 

Ésta segunda opción se puede lograr paulatinamente a través de semi- 
narios graduales de “sensibilización” hacia los “usuarios”. El objetivo es 
que conozcan la “caja negra”, sepan de sus bondades, distingan entre los 
riesgos y olviden el “fantasma del cómputo”. Cuando dominen la herra- 
mienta, el producto será de muy alta calidad. 

Dominar la herramienta no implica convertirlos en especialistas de 
cómputo. Lo que se persigue es enseñarles la filosofía de la computación, 
así como proporcionarles los conceptos necesarios para que comprendan 
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el funcionamiento y la operación de estos equipos. 
El resto llegará como consecuencia del interés, inquietud e ingenio 
natos del “usuario”. 
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En Estados Unidos y otros países las computadoras ya eran utilizadas 
de manera productiva desde finales de los cuarenta; veinte años después, 
comenzaron a utilizarse en México. Nuestro nivel técnico respecto a este 
campo se ha visto estancado durante mucho tiempo. Es evidente que si los 
profesionales del medio aún no logramos aprovechar debidamente esta 
tecnología es por que no la hemos asimilado en su plena magnitud; cómo 
podemos pedir que los usuarios, a los que nosotros mismos hemos relega- 
do, se integren rápidamente y se responsabilicen del manejo de la infor- 
mación con el sólo hecho de ponerles una terminal de video enfrente, 
Tenemos que comprender que la computadora siempre se le ha presenta- 
do al usuario como una “caja negra”. Cierto es que se va haciendo más 
estrecho el tramo que separa al usuario de la computadora, a través de 
nuevos métodos y tecnología más avanzada. Pero también es cierto que la 
integración del usuario no puede ser automática. Para lograr eso es funda- 
mental que quienes conocemos el ramo guiemos al usuario y lo capaci 
mos en forma paulatina hasta lograr que la “caja negra” le sea descubierta 
sin complicaciones, sin temores, sin elucubración; más bien con senci- 
llez, con objetividad y con los conceptos necesarios para que los usuarios 
comprendan conceptualmente el funcionamiento de estos equipos y sean 
ellos mismos quienes se integren cuando sientan que están preparados, y 
no presionados por nuestra prisa. Nosotros los técnicos estamos obligados 
a facilitarles la transición. 
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Auditoría técnica: ¿por 
qué?, ¿para qué? 


Problema 


Casi ninguna Instalación de Informática 
realiza auditorías técnicas periódicas para 
obtener diagnósticos de su situación, y así 
poder superar sus deficiencias en gran medida. 


En todo centro de cómputo existen desacuerdos en cuanto a cuál es la 
mejor manera para lograr una coordinación efectiva entre las distintas 
áreas que lo conforman. Es común que cada área tenga autonomía en su 
modo de trabajar. Sin embargo, el trabajo que desarrolla un área y la 
manera como lo hace, necesariamente afectan, de un modo o de otro el 
trabajo de las áreas circunvecinas. 

Por lo general se olvida que ningún área por sí sola puede lograr los 
objetivos globales de procesamiento de datos. Para alcanzarlos es indis- 
pensable que existan acuerdos claros y específicos sobre los procedimien- 
tos que deberán seguirse desde la captura de datos hasta la obtención de 
resultados; desde la definición de programas hasta la obtención de resul- 
tados de las pruebas integrales de cada sistema a liberar; desde la distribu- 
ción de resultados hasta la correcta utilización de ellos por parte de los 
usuarios de la información. En todas las etapas intermedias deberá existir 
un completo conjunto de acuerdos y comunicados que permitan visuali- 
zar siempre información veraz y oportuna. 

Esto quiere decir que deberán existir métodos de trabajo individuales 
por cada área que regulen, los cuales comuniquen e interrelacionen el 
trabajo como un todo, porque de no ser así, cada área trabajará a su mane- 
ra sin importar lo que las demás hagan ni la manera como realicen su tra- 
bajo. Esto sólo ocasiona errores frecuentes y costosos que al final todos 
tratan de eludir. 
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El objetivo de las auditorías técnicas es cómo involucrar un ámbito 
entre todas las áreas, de manera que sea posible comprobar con un alto 
grado de acierto si todos los procedimientos establecidos logran fluidez, 
e asistencia y oportunidad en el desarrollo del procesamiento de datos; 
encontrar los puntos críticos que lo entorpecen y promover soluciones 
rápidas; además de hacer críticas estrictas de tales procedimientos y con- 
firmar si esa es la mejor forma de hacerlo o es factible optimizarlos. 


SUGERENCIAS DE SOLUCIÓN 


1. Es recomendable que toda instalación realice auditorías técnicas, 
ya sea por especialistas propios, por asesores externos dedicados a estas 
Íabores, o por técnicos de otra instalación modelo. 

2. Las auditorías deberán ser periódicas (cuando menos una por año) 
porque casi siempre se encuentran fallas tan sutiles que difícilmente son 
detectadas en revisiones superficiales; sin embargo, con frecuencia resul- 
tan ser la causa principal de los fracasos de la instalación. 

3. Cada auditoría deberá hacerse a profundidad y atendiendo cada área 
por separado para que al final sea más fácil comprobar si éstas se encuentran 
interrelacionadas en forma congruente. Á continuación se muestran cues- 
tionarios base con los cuales es posible iniciar una auditoría por área de 
acción. 


a) Auditoría en el área de análisis y diseño de sistemas. 


+ ¿Qué metodología se sigue en los diseños? 

e ¿Trabajan todos los analistas con base en la misma metodología? 

+ ¿Cómo documentan el diseño de un sistema? 

+ ¿Qué método siguen para actualizar la documentación cuando 
hay cambios en los sistemas ya en operación? 

+ ¿Cómo definen los programas para su elaboración? 

+ ¿Cómo critican y se aseguran que los programas son confiables 
para ponerlos en producción? 

+ ¿Qué tipo de controles establecen para hacer cambios en los siste- 
mas ya en producción? 

+ ¿Los sistemas están diseñados por módulos que facilitan su man- 
tenimiento? 

+ ¿Qué tipo de controles utilizan para sostener la integridad de los 
sistemas? 

+ ¿Desarrollan labor de optimización de sistemas? 

+ ¿Qué etapas se deben cubrir para liberar un sistema a produc- 
ción? 
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b) 
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+ ¿Prevén respaldos automáticos de información en los sistemas? 

+ ¿Cómo determinan los niveles de analistas dentro de la instala- 
ción y cuáles son sus perfiles técnicos? 

+ ¿Normalmente cuántos analistas y de qué nivel intervienen en el 
desarrollo de un sistema completo? 

+ ¿Planean su capacitación por objetivos? 


Auditoría en el área de programación. 


+ ¿Qué metodología se sigue en la elaboración de los programas? 
+ ¿Programan bajo la misma metodología todos los programadores 
le esta área? 

+ ¿Cuántas compilaciones promedio se requieren para depurar un 
programa con errores de sintaxis? 

+ ¿Cuántas corridas promedio de prueba se requieren para obtener 
resultados correctos de un programa? 

+ ¿Cómo y quién define los datos prueba para los programas? 

+ ¿Cómo se aseguran de que los datos prueba cubren todas las con- 
diciones posibles? 

+ ¿Cómo y quién determina el tiempo que se requiere para la elabo- 
ración de cada programa? 

+ ¿Cómo estructuran la documentación de cada programa? 

+ ¿Programan bajo la Filosofía estructurada? 

+ ¿Cómo controlan las modificaniones a que son sujetos los pro- 
gramas? 

e ¿Mantienen actualizada la documentación de cada programa? 

«¿Cómo se difunden las experiencias de los programadores? 

e ¿La capacitación se plantea bajo objetivos? 

+ ¿Hacen los programadores labor de investigación técnica? 

+ ¿Todos los programas arrojan cifras de control? 

+ ¿Cómo y quién determina que un programa sea confiable para 
Liberarse a producción? 

e ¿Cómo y quién determina la complejidad y asignación de cada 
programa? 

+ ¿Existen estándares de programación? 

+ ¿Cómo se determina el nivel y perfil técnico de un programador? 


Auditoría en el área de sistemas operativos. 


+ ¿Qué metodología siguen en la generación de los sistemas opera- 
tivos? 

+ ¿Cada cuando suben el nivel de los sistemas operativos y en qué 
basan esa decisión? 


d) 
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+ ¿Cuál es el método de prueba para las nuevas versiones de los sis- 
temas operativos? 

+ ¿Cómo evalúan los paquetes de software susceptibles de instalarse? 

< Una vez instalado un nuevo paquete de software o sistemas ope- 
rativos, ¿qué procedimiento siguen para que los usuarios conoz- 
can y usen las nuevas facilidades soportadas? 

© ¿Cómo corrigen las fallas de los paquetes y del sistema operativo, 
y cómo prueban tales correcciones? 

+ ¿Cómo van controlando el mantenimiento y cambios a paquetes 
y al sistema operativo? 

e ¿Existen políticas de uso para paquetes y sistema operativo? 

+ ¿Cuáles son los procedimientos de respaldo y recuperación del 
sistema operativo? 

+ ¿Cómo mantienen y depuran la asignación de espacio en discos? 

+ ¿Hacen labor de afinación del sistema operativo? 

+ ¿Cuáles son los estándares de documentación de esa área? 

e ¿Monitorean permanentemente el comportamiento del equipo 
de cómputo? 

+ ¿Qué estadísticas obtienen sobre el uso del computador? 

+ Cómo determinan el nivel y perfil técnico de un programador 
UEA operativos? 

« ¿Establecen estándares de nomenclatura para los archivos? 


Auditoría en el área del teleproceso. 


+ ¿Quién determina la estructura de la red de teleproceso? 

« ¿Son los tiempos de respuesta los deseados? 

+ ¿Existen procesos rápidos para restablecer el se: 
ceso en caso de caída? 

+» ¿Cómo están documentados los procedimientos de recupera- 
ción? 

+ ¿Llevan estadísticas sobre las transacciones del servicio de tele- 
proceso? 

+ ¿Bajo qué condiciones y cómo prueban nuevas aplicaciones de 
teleproceso? 

+ ¿Planean la capacitación de los usuarios del teleproceso? 

e ¿Tienen establecidos sus niveles de servicio? 

+ ¿Qué niveles de seguridad tienen establecidos para el acceso a los 

atos, vía teleproceso? 

+ ¿Existen estándares de documentación dentro de esta área? 

+ ¿Cómo determinan el nivel y perfil técnico de los integrantes de 
esta área? 

+ ¿Existe capacitación por objeti.os? 


io de telepro- 
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e) Auditoría en el área de operación. 


+ ¿Cuántos IPL se dan a diario? 

+ ¿Cuáles son las razones más frecuentes? 

+ ¿Registran las razones de éstos? 

+ ¿Siguen procedimientos plenamente documentados que los guíen 
al tratar de recuperar fallas de hardware y software en los compo- 
nentes críticos? 

e ¿Tienen calendarios establecidos para el mantenimiento del 
computador? 

+ ¿Cómo reconstruyen archivos dañados? 

« ¿Existen calendarios para el control de la producción? 

+ ¿Qué procedimientos siguen en la distribución de resultados? 

+ ¿Cómo verifican que los resultados sean correctos? 

+ ¿Cuál es el nivel normal de multiprogramación? 

+ ¿Qué procedimiento siguen cuando existe alguna falla en los 
programas de producción? 

+ ¿Cómo identifican los archivos en cinta magnética? 

la ¿Cuáles son las causas más frecuentes por las que se interrumpe 
el servicio? 

+ ¿Existen procedimientos de resguardo de la información? 

+ ¿Los planes de capacitación son por objetivos? 

+ ¿Cómo determinan el nivel y perfil técnico de los operadores? 
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Es común que dentro de la organización de un centro de cómputo 
cada área trabaje a su modo, sin tomar en cuenta que la manera de hacer- 
lo necesariamente afecta el desempeño de las áreas circunvecinas. Por lo 
general se olvida el hecho de que ningún área, por sí sola, puede lograr 
los objetivos globales del procesamiento de datos. En todas las etapas 
intermedias deberá existir un completo acuerdo y eficiente comunica- 
ción para coordinar esfuerzos. Los métodos de trabajo que se implanten 
deberán considerar este aspecto, el cual no debe ser producto de eventya- 
lidades no encauzadas, sino que deben estar perfectamente reglamenta- 
dos los canales de comunicación y límites de acción y responsabilidad 
entre áreas. El objetivo de la auditoría técnica es cómo involucrar un árbi- 
tro que regule las actividades entre las distintas áreas del centro de 
cómputo. Á la par, el proceso de auditoría consistirá en detectar deficien- 
cias en el desarrollo del trabajo; desde la captura de información hasta la 
obtención de resultados en el computador, y hacer el seguimiento oportu- 
no para corregir cabalmente las fallas detectadas. Toda instalación deberá 
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realizar auditorías técnicas periódicas, ya sea por personal interno dedica- 
Mo a estas labores, o por consultores externos expertos del ramo. Se deberá 
uclitar cada área por separado a fin de conocer si sus actividades se com- 
plementan ordenadamente con las áreas restantes. La auditoría técnica es 
Dña buena práctica, sobre todo en instalaciones grandes propensas al 
desorden y a la falta de comunicación. 
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Evaluación de software 


Problema 


Muchas Instalaciones acostumbr 
adquirir paquetes de software que a la postre 
resultan de escasa o nula utilización. 


Con el avance de la tecnología en materia de hardware, se ha hecho 
posible que los equipos de cómputo se vuelvan cada vez más económicos. 
Por el contrario, el software se ha encarecido y con frecuencia se vuelve 
difícil de encontrarlo en el mercado, de manera que sea ajustable a las ver- 
daderas necesidades de cada instalación. Es conocido que algunas compa- 
ñías distribuidoras y fabricantes de equipo de cómputo han lanzado con- 
vocatorias para fusionarse con otras compañías o grupos que se dedican al 
desarrollo de software, elevándose así por esta demanda los costos de 
dicho software. 

Sin importar que este fenómeno sea cada vez más grave, muchas ins- 
talaciones han adquirido el vicio de comprar prácticamente cualquier 
paquete software que se les ofrece, aun cuando saben que sólo harán poca 
utilización del mismo. Si a lo anterior agregamos que sólo en contadas 
ocasiones se toma en cuenta al usuario, que se supone recibirá el servicio, 
encontramos que Finalmente se compra sin objetivos claros y, por tanto, 
con muy pocas posibilidades de un uso efectivo de tales paquetes. 

Existen instalaciones que por no hacer una evaluación seria compran 
paquetes que en poco tiempo resultan obsoletos o son incompatibles con 
otros equipos de la misma instalación. Al paso del tiempo se encuentra 
que la instalación sigue pagando mantenimiento para varios paquetes que 
no han sido utilizados. 

Esto se traduce en un gasto infructuoso y elevado en la mayoría de los 
casos. No hay necesidad de que esto suceda sí hacemos un estudio preli- 
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minar, no muy tedioso, para demostrar la conveniencia de la adq 
de tal o cual producto de software. Seguir comprando a ciegas y sin un fin 
especifico y costeable, sólo representará incrementar el presupuesto de 
un centro de cómputo, lo cual a nadie beneficia. Es preferible aprovechar- 
lo para requerimientos más necesarios. 

Es inaudito que algunas instalaciones argumenten que habrán que 
gastar lo presupuestado para este año por concepto de compra de softwa- 
re, porque sí no el siguiente ya no les será autorizado un presupuesto 
similar o mayor, y más vale que sobre y no que falte. Por eso habrá que 
gastarlo en lo que sea. Tales argumentos sólo reflejan una falta de sentido 
profesional y de responsabilidad. 


SUGERENCIAS DE SOLUCIÓN 


En primer lugar, ninguna sugerencia surtirá efecto si partimos del 
argumento anterior. Aun así, una opción más sensata es establecer que el 
alcance del presupuesto por compra de software será dado no en forma 
anual ni con un estimado teórico, que más bien es ilógico. Es preferible 
que cuando existe la necesidad de la evaluación de algún paquete de soft- 
ware y se demuestre su verdadera justificación, sean los directivos usua- 
rios, quienes vayan a recibir el servicio, los que lo absorban dentro de su 
presupuesto particular, En otras palabras, que este tipo de presupuestos 
los administre el propio usuario. A fin de cuentas los usuarios son los 
que verdaderamente hacen uso de los servicios de cómputo. Los técni- 
cos del área de procesamiento de datos sólo deberían ser los responsables 
de llevar a cabo la evaluación preliminar y las sugerencias de adqui- 
sición con la garantía de que será un software de alto beneficio para 
dicho usuario; y éste será quien dictamine la necesidad final de adqui- 
rirlo. Algunas instalaciones ya llevan a la práctica este procedimiento y 
los resultados han sido evidentemente mejores que los gastos infructuo- 
sos ya mencionados. 

Las fases que deberá cubrir una evaluación de software, en el sentido 
serio y profesional, se enmarcan a continuación: 


Fase 1. Cuando se identifica la necesidad concreta de algún usuario para la 
adquisición de algún paquete de software, lo primero que habrá que 
hacer es formar un comité entre el grupo de especialistas técnicos del 
centro de cómputo y los responsables del proyecto por parte del usua- 
rio, quienes conocen sus verdaderas necesidades de información. 

Fase 2. Dentro del comité, el usuario dará una plática detallada sobre los 
objetivos de información que se persiguen, para que el personal técni- 
co capte las verdaderas necesidades. 
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Fase 3. Una vez comprendidos los objetivos concretos por parte de los 
integrantes del comité, el grupo técnico hará un análisis del mercado 
para conocer cuáles productos cubren las necesidades específicas del 
proyecto. Para identificar el producto más idóneo, se deben conside- 
rar los siguientes parámetros de evaluación: 


. Alcance práctico del producto. En este punto habrá que tomar en 
cuenta si las facilidades que ofrece el producto cubren en su totali- 
dad los requerimientos del usuario. Para esto será indispensable 
que si el producto cubre, además del 100% de las necesidades 
detectadas, algunas otras, habrá que encontrarles una utilidad 
práctica para explotarlo en toda su magnitud. 

2. Compatibilidad con el software existente, Es determinante que el 
producto sea completamente compatible con el software de la ins- 
talación, pues no es conveniente realizar cambios ni de un lado ni 
de otro, a menos que dichos cambios sean superficiales y no distor- 
sionen la filosofía original del producto (entiéndase como cambios. 
superficiales la adecuación de algunos parámetros solamente). 

3. Sencillez para la explotación del producto. Algo muy importante 
es que el uso del producto sea lo más sencillo para el usuario, de 
manera que le simplifique el trabajo en vez de someterlo a una 
especialización profunda y lenta. Si esto no se cumple, el uso del 
producto tiende a olvidarse. 

4. Mantenimiento para actualizaciones futuras. El producto debe ser 
sujeto de cambios rápidos y sencillos para cubrir posibles modifica- 
ciones, requeridas por el usuario, en atención principalmente a las 
que se generan por cambios legales. Es decir, debe ser un producto 
flexible, factible de ser modificado a partir de parámetros y no por 
efecto de modificaciones en el cuerpo de los programas. 

5. Sencillez para la instalación del producto. Algo importante de eva- 
luar también es la sencillez de la instalación, ya que hay productos 
que hacen muy fluida a ésta y no se requiere de personal especiali- 
zado para tal fin. Existen productos de instalación compleja que 
requieren especialistas que es difícil conseguir o capacitar. Si este 
es el caso habrá que considerarlo si no existe opción. 

6. Soporte por parte del proveedor. Es importante, durante la evalua- 

ión, que exista personal del proveedor, capacitado para prever, 

por si se presentara, algún problema difícil de resolver en forma 
local, y atenderlo inmediatamente. 

7. Material didáctico que proporciona el proveedor. Habrá que con- 
siderar si el material didáctico para la explotación del producto es 
completo y de calidad, sobre todo que se apegue al nivel del usua- 
rio, para lograr una explotación inmediata y completa de las facili- 
dades que proporciona. 
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8. Cantidad de usuarios del producto en el mercado. Un buen punto 
de comparación, que incluso dará más confianza en la adquisición 
del producto idóneo, es investigar en el mercado alguna instala- 
ción que lo tenga en operación, a fin de intercambiar opiniones 
que sean de beneficio para el dictamen. 

9. Costo del producto. En términos económicos, hay que tomar en 
cuenta el costo del producto para hacer un análisis de costo-beneficio 
y poder determinar la conveniencia de la adquisición. 


Fase 4. A fin de lograr una selección más ventajosa, es recomendable que, 
partiendo de la evaluación anterior, se consideren un máximo de tres 
proveedores y a cada uno por separado se le pida una demostración en 
la cual sea posible hacer una prueba completa en el ambiente del 
usuario que recibirá el servicio. 

Fase 5. Se procederá a efectuar una junta de trabajo entre los miembros 
del comité cuyo objetivo sea determinar la decisión con respecto al 
producto a adquirir; se elaborará también un documento oficial que 
contenga los siguientes aspectos: 


a) Índice, 

b) Descripción de los objetivos a cubrir con el producto. 

c) Lista de compañías proveedoras a las que se trató. 

d) Procedimiento de selección que se cubrió para la selección del pro- 
ducto. 

e) Análisis de costo-beneficio, donde se enmarque el nivel de utiliza- 
ción del producto con respecto a sus facilidades. 

f) Aplicaciones en que se explotará el producto. 

g) Observaciones y recomendaciones finales. 

h) Firmas de los integrantes del comité. 


Fase 6. Iniciar trámites de adquisición. 


Una vez adquirido el producio, se procederá a realizar el procedi- 
miento de instalación y puesta en marcha, a través de las siguientes fases 
de control: 


Fase 1. La recepción de cualquier producto de software estará centrado 
en la mesa de control de la instalación, cuyo responsable comprobará 
que el material está completo, auxiliándose de la relación que acom- 
paña dicho producto. Si detecta que viene incompleto, lo rechazará 
de inmediato. En caso contrario, firmará de recibido. 

Fase 2. Una vez recibido el producto, deberá darlo de alta en la relación 
de software que para tal fin existe; al mismo tiempo, pasará la comu- 


PE CAP. 11. EVALUACIÓN DE SOFTWARE 


nicación formal al departamento de soporte técnico. Dicha comuni- 
cación contendrá lo siguiente: 


a) Nombre del producto 
b) Fecha de recepción 
e) Nivel de actualización o versión de release. 


d) Clave del producto. 


Los elementos de que consta el producto, como son: manuales, cin- 
tas, instructivos, etc., serán centralizados en la mesa de control, cuyo 
encargado lleva registro y control estricto. 

Fase 3. Es recomendable sacar copias de manuales, cintas, instructivos, 
ete., para tener siempre un respaldo en caso necesario. 

Fase 4. Los elementos del producto original deberán quedar centraliza- 
dos en lugar previamente definido, de manera tal que a partir de ese 
momento sólo se trabaje con las copias. 

Fase 5. Al momento de decidir la instalación de cualquier producto, la 
persona asignada para ello deberá solicitar los elementos necesarios a 
la mesa de control, quien a su vez llenará una forma que contenga los 
siguientes datos: 


a) Nombre de la persona que requirió el producto. 

b) Fecha y hora. 

e) Nombre de cada elemento requerido, así como su identificación 
individual. 

d) Fecha y hora de devolución de los elementos requeridos cuando el 
producto haya quedado instalado. 

e) Firmas de entrega y devolución de ambas personas. 


Fase 6. El responsable de la instalación hará un estudio a conciencia 
sobre el procedimiento de instalación; además, deberá elaborar una 
lista de verificación detallada sobre los pasos de instalación. 

Fase 7. Con base en la lista de verificación previamente elaborada, se 
procederá a instalar dicho producto. Como resultado de la instala- 
ción, se deberá estructurar una carpeta documental que contenga, 
aparte de la lista de verificación, todos los listados producto de la ins- 
talación, así como notas explicativas de las experiencias encontradas 
durante el proceso de instalación. Eso será muy valioso para consultas 
Futuras. 

Fase 8. Después de la instalación se realizarán pruebas exhaustivas, las 
cuales deberán ser avaladas por el usuario que recibirá el servicio. 

Fase 9. Se capacitará al usuario para hacerlo autosuficiente en el uso del 
producto si ese fuera el caso. 


RESUMEN DEL CAPÍTULO 11 Tr 


Fase 10. Finalmente, después de liberar a producción el producto, se 
entregarán a la mesa de control los elementos solicitados en un prin- 
cipio, así como la carpeta documental que contenga los antecedentes 
de la instalación. 
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Pese a que los últimos años se ha incrementado en forma desmesura- 
da el costo del software, muchas instalaciones han adquirido el vicio de 
comprar lo que les ofrezcan sin haber evaluado a conciencia la real utiliza- 
ción de éste en su medio. Por lo general no se toman en cuenta las opinio- 
nes de los usuarios para adquirir productos que en verdad se ajusten a sus 
necesidades de servicio. Existen instalaciones que, por no hacer una eva- 
luación seria, compran paquetes que en poco tiempo se vuelven obsole- 
tos o son incompatibles con otros equipos de la misma instalación, don- 
de también se debieran utilizar. Lo peor es que algunas instalaciones 
argumentan que habrá que gastar el presupuesto para ese año porque de 
lo contrario, al año siguiente ya no se les autorizará. Es recomendable 
para hacer compras de software más provechosas, que se forme un comi- 
té entre técnicos y usuarios; que el presupuesto asignado a este rubro sea 
manejado por los propios usuarios. Deberán existir reglamentos oficia- 
les que permitan evaluaciones exhaustivas y confiables; y se deberán 
Sa lementar métodos de trabajo para la instalación de todo producto de 
software. 
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El enigma de las bases 
de datos 


Problema 


Las Instalaciones que han decidido 
cambiar a la estructuración de bases de 
datos difícilmente han conseguido resultados 
a corto plazo debido a inmadurez técnica y 
falta de técnicos especializados. 


La tecnología en el campo de la electrónica alcanzó avances signifi 
cativos en muy pocos años. En un corto periodo se diseñaron computa- 
doras bastante rápidas en sus tiempos de proceso, cuya velocidad, que en 
algún tiempo se cuantificaba en términos de microsegundos, pasó a ser 
mucho menor. Esto representó un verdadero logro en el diseño del 
hardware porque también se diseñaron periféricos capaces de ser con- 
gruentes con la velocidad alcanzada por la unidad central de proceso. 
in embargo, surgió un problema serio: ei software no logró el mismo 
desarrollo, y por tanto, seguía siendo tradicional, principalmente en la 
organización de datos y sus métodos de acceso; es decir, en comparación 
con el hardware, éstos seguían siendo casi primitivos, haciendo que la 
velocidad de la computadora fuera frenada en gran medidad. De esta 
manera, los ingenieros en diseño de software se vieron precisados 
desarrollar un nuevo concepto, llamado bases de datos. Este propósito; 
entre otras cosas, perseguía aprovechar la velocidad de la computadora, 
surgiendo así una variedad de nuevos arreglos de datos, acordes con el 
avance del hardware. 

En la actualidad existen en el mercado distintos tipos de bases de datos; 
desde las de estructuras jerárquicas hasta las llamadas relacionales; existen 
también las estructuradas por redes llamadas asociativas, asi como otras que 
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sustentan calificativos pomposos como argumento comercial. 

Es verdad que dichos tipos de organización de datos son mejores que 
los anteriores y superan con mucho las facilidades tradicionales, pero 
también es cierto que los requerimientos técnicos necesarios para un 
aprovechamiento eficiente, tanto en hardware como en software, superan 
a los anteriores. Es más, los conocimientos técnicos de los encargados de 
generar, diseñar y mantener las bases de datos no se alcanzan de un día 
para otro; por el contrario, es necesaria la formación de especialistas del 
ramo. Esto por supuesto no puede ser un argumento de venta y por ello se 
tiende a disfrazar, originando que quienes por entus/asmo o por una 
auténtica necesidad, deciden adquirir algún paquete de bases de datos, 
por lo general tarden mucho tiempo para lograr un buen aprovechamien- 
to de sus bases de datos. 

Con lo anterior no se pretende afirmar que las bases de datos sean 
malas o que representen un gasto elevado e infructuoso. Al contrario, 
estoy convencido de que la gran mayoría de las instalaciones, grandes o 
medianas, requieren por necesidad cambiar al concepto de bases de datos. 
Para demostrarlo, veamos algunos beneficios que de ello resultan: 


+ Se adquiere una gran flexibilidad para estructurar registros de datos 
con longitud variable dentro de una misma base de datos. 

+ Se permite una amplia posibilidad en la eliminación de datos redun- 
dantes. 

+ Se fortalece la capacidad para limitar a los usuarios de manera que 
sólo puedan acceder a datos a los que están autorizados, lo cual se 
traduce en un amplio rango de confidencialidad. 

+ Se logra un buen ahorro de espacio en dispositivos de discos, ya sea 
por la eliminación de redundancia de datos o por los nuevos méto- 
dos de cálculo de espacio requerido. 

+ Existen mejores métodos de acceso optimizados, con lo cual se logra 
aprovechar en forma eficiente la velocidad de la computadora. 

S amplía la versatilidad en la programación para el manejo de 

latos. 

+ Se permite que una misma base de datos sea la fuente para varios sis- 
temas relacionados. 

+ Se puede estructurar una misma base de datos por fases, lo que per- 
mite desarrollar también sistemas por fases, pudiendo obtener así 
resultados en forma casi inmediata, sin necesidad de haber conclui- 
do la implantación de sistemas completos. 

+ Existe una amplia posibilidad y flexibilidad para hacer preguntas no 
planeadas sobre el contenido de los datos, así como la obtención de 
reportes y estadísticas sólo con la codificación de algunos comandos 
de control. 
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+ Para los sistemas de teleproceso y accesos en tiempo real, es evidente 
que, dadas las facilidades anteriores, son la organización de datos 
ideal. 


Es fácil comprender las enormes ventajas que representan el uso de 
bases de datos en el ámbito informático, pero lo que no resulta tan cierto 
es la supuesta facilidad para estructurarlas, explotarlas, administrarlas y 
mantenerlas. No se piense que este es un comentario suelto o mera espe- 
culación mía, basta acudir a las instalaciones que lo han intentado para 
conocer la gran cantidad de tiempo y dolores de cabeza que les ha repre- 
sentado. Habrá que decir que muchas instalaciones no han logrado, por 
lo menos, estructurar correctamente sus bases de datos, ya que no han 
pasado de crear un gran archivo que dista mucho de ser una base de datos. 
Otras instalaciones, no pocas, no cuentan ni con un grupo de técnicos 
capacitados para no sólo estructurar sus bases de datos, sino para conocer 
qué especialidades tiene que cubrir. La prueba está en aquellas instalacio- 
nes que han adquirido este tipo de paquetes y después de va 
siguen esperando a alguien que les ayude en la generación de los mismos. 
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La problemática expuesta tiene su raíz en que la mayoría de las ins 
talaciones se han aventurado hacia un terreno desconocido, sin haber- 
se tomado la molestia de investigar a conciencia los requirimientos téc- 
nicos y humanos necesarios para participar con éxito en este nuevo 
entorno. Han permitido que lo novedoso del concepto y lo ventajoso 
de sus facilidades los arrollen como una gran ola y ahora se ahogan en 
un mar de problemas. Es inconcebible que se emprenda una aventura 
donde el argumento de juego sea lo más valioso de un centro de 
cómputo, es decir, sus archivos de datos. Los que ya emprendieron la 
aventura, en la mayoría de los casos, están más ocupados en atender su 
propio rompecabezas que en escuchar sugerencias; sin embargo, con- 
fío en que hayan aprendido lo suficiente de sus errores, que cuando 
menos se ocupen en encontrar las mejores opciones correctivas. Para 
aquellos que prefieren ir sobre pasos firmes al emprender cualquier 
tarea, y sobre todo una de tal envergadura, seguramente les resultarán 
de gran interés las siguientes recomendaciones al respecto: 


+ Entender perfectamente los requerimientos técnicos de hardware, 
software y de especialización de personal, antes de adentrarse en el 
ámbito de las bases de datos. 

e Visualizar con detenimiento los objetivos de servicio, resultados 
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específicos y niveles de información que se pretenden. 

« Determinar con precisión los volúmenes de datos con los que ope- 
ran en la actualidad y las estrategias más viables de conversión de 
archivos tradicionales a concepto de bases de datos. 

+ Hacer un inventario de los sistemas a implantar y determinar la 
interrelación que existe entre ellos. 

+ Hacer una estructuración específica de áreas especializadas para el 
diseño, administración y mantenimiento de las bases de datos. 

+ Considerar que se tendrá que hacer una reevaluación en las labores 
de análisis y diseño de sistemas, para el mejor aprovechamiento de 
este nuevo concepto. 

« Estructurar un plan estratégico para la integración del concepto de 
bases de datos, a fin de ir cubriendo con rigor todos los prerrequisi- 
tos a considerar, antes de intentar la definición conceptual de sus 
nuevos diseños. 

«+ Buscar la asesoría de un especialista de bases de datos, no represen- 
tante del producto de adquirir. 

+ No improvisar técnicos queriendo ganar tiempo, sino adquirir con- 
ciencia de que llevará un buen periodo la preparación sistemática de 
los mismos. 

e Visitar instalaciones modelo en donde se han implantado bases de 
datos y averiguar la realidad de lo que esto les ha representado en 
tiempo y esfuerzo, 

+ Evaluar distintos paquetes que ofrecen en el mercado para seleccio- 
nar aquel que reúna las carecterísticas más ventajosas para su medio 
ambiente particular. 

+ Jamás, y lo digo muy en serio, entrar en negociación con algún pro- 
veedor a primera vista. 
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Así como la tecnología avanzó en gran medida en el desarrollo de 
hardware, fue necesario inventar nuevas técnicas en el arreglo de datos 
y en los métodos de acceso. De esta manera se abordó el concepto de las 
bases de datos. Sin embargo, todo sucedió tan rápido que confiamos en 
que se simplificaría el panorama para las instalaciones que decidieron 
adoptarlas. Este error lo hemos pagado muy caro, ya que existen insta- 
laciones que han emprendido la aventura más por entusiasmo que por 
un convencimiento pleno de lo que ello implica. Cierto es que este 
nuevo tipo de organizaciones de datos superan con mucho a las tradi- 
cionales, pero también es cierto que los requerimientos técnicos para 
una explotación eficiente superan demasiado a los anteriores. Las 
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bases de datos son necesarias actualmente dado el crecimiento expo- 
nencial que ha tenido la información, sin embargo habrá que tomar 
muy en serio el cambio a este nuevo enfoque, y sobre todo prepararse 
en forma sistemática para abordarlo. No resulta fácil ni rápido, como 
argumentan los proveedores de los productos que ofrecen en el merca- 
do. Para integrarse al ámbito de las bases de datos será necesaria la crea: 
ción de un área de especialistas que las exploten, administren y man- 
tengan. Por imprudencia se ha permitido que lo novedoso del tema y lo 
ventajoso de sus facilidades nos haya arrollado como una gran ola y 
ahora nos ahoguemos en un mar de problemas. Los que ya emprendie- 
ron la aventura se preocupan más en salir del atolladero que en escu- 
char sugerencias. Los que aún no la han intentado no se detengan, pre- 
párense primero y busquen el momento preciso cuando hayan reunido 
todos los prerrequisitos necesarios para ingresar a este campo. 
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Los métodos de trabajo 
y sus beneficios 


Problema 


No existen metodologías de trabajo. y 
donde las hay. dificilmente son respetadas. 


Una metodología de trabajo se puede definir como el conjunto de 
operaciones específicas que permiten conocer con acierto la manera y 
secuencia con las que deberá efectuarse una labor, así como estandarizar 
los eventos rigurosos a los que deberán sujetarse dichas operaciones. 
Esto, entre otras cosas, permite visualizar la calidad de la actividad desa- 
rrollada por cada integrante, y en consecuencia, las deficiencias de los 
mismos. 

Es un hecho que todo tipo de trabajo requiere de un orden en el desa- 
rrollo de cada actividad; no importa si el trabajo es sencillo o laborioso, de 
cualquier manera será necesario establecer un esquema lógico de pasos 
por cada operación que interviene, Será necesario dictar lineamientos de 
control para obtener productos estándares en acabados y calidad. 

A pesar de que en el ámbito informático esto es un factor vital para el 
arrollo de los sistemas y su operación, amén del mantenimiento de los 
mismos, Frecuentemente se viola esta regla. Los resultados son evidentes 
en muchas instalaciones que la pasan por alto, y las consecuencias son 
muy costosas, tanto en tiempo como en dinero, pero mucho más en resul- 
tados incompletos, desfasados y de pésima calidad, que no reúnen los 
mínimos de regularidad para garantizar resultados veraces y oportunos a 
los usuarios de información. 

¿Por qué no existen metodologías o por qué no se respetan cuando 
las hay? La respuesta es sencilla: ¡No hay tiempo! ¡Los resultados las 
requieren ya! 


des 


orientación a los directivos; jefes inmaduros o con pésimos conoci- 
mientos técnicos y administrativos en matería computacional. En 
general, falta de profesionalismo de quienes aceptan el desorden y de 
aquellos que lo propician. 
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1. A lo largo de nuestras entrevistas, encontramos situaciones de 
terrible desorden por no haber lineamientos de trabajo, no digamos efi- 
cientes sino básicos para el buen funcionamiento de cada área. Por esta 
razón, cada técnico trabaja de acuerdo con sus posibilidades, resultan- 
do un descontrol tal que nadie sabe a ciencia cierta cuál es la situación 
real de los proyectos en desarrollo; en los casos de aquéllos ya en pro- 
ducción, los problemas son tan frecuentes que casi siempre hay necesi- 
dad de hacer trabajos de mantenimiento, no por obtener nuevos resul- 
tados sino por la mala calidad de éstos, lo cual es inconcebible en 
sistemas en producción. Esto provoca costos elevados y de toda índole, 
sólo porque nó hubo previsión y orden para tales situaciones. Los jefes 
de cada área son los únicos responsables de que esto suceda, y la reco.. 
mendación urgente es que se invierta el tiempo necesario para estable- 
cer sus propias metodologías; que se percaten de que esta inversión 
será tan provechosa y menos larga que todo el tiempo que se pierde en 
los ajustes futuros. 

El jefe de cada área deberá estar preparado para hacerlo. Si por razo- 
nes obvias no lo está, será necesario que se documente y tome cursos al 
respecto en forma inmediata. Si no quiere hacer esto, entonces pida que 
se haga con recursos externos a la compañía, por consultores experimen- 
tados. Piense que será un trabajo de una sola vez y los frutos del mismo se 
obtendrán durante mucho tiempo. 

2. En ciertos casos asistimos a instalaciones donde quedamos asom- 
brados con los procedimientos de trabajo establecidos, los cuales estaban 
perfectamente documentados. En algunos casos habían sido desarrolla- 4 
dos por personal propio de la instalación, incluso por áreas esiablecidas ex 
profeso; y en otros por consultores externos. Sin embargo, nuestro asom- 
bro fue mayor cuando comprobamos que casi nadie los respetaba. Esto es 
responsabilidad absoluta de los jefes que lo han permitido. No basta con 
definir las metodologías y guardarlas. Es necesario una supervisión y una 
continuidad para asegurar que éstas se lleven a la práctica. Establezca 
puntos de control en los cuales un trabajo no pueda continuar sí éste no se 
ha apegado a dichos lineamientos. Investigue las causas, y si es necesario, 
despida al personal que no quiera sujetarse a dichas normas. Ya hemos 
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hablado bastante sobre la responsabilidad que concierne a los jefes, y con- 
tinuaremos haciendo énfasis sobre las funciones del mismo cuando se vea 
que ahí radica el mal. Sin embargo, los técnicos deberán apoyar con pro- 
decionalismo las estrategias prudentes y sanas impuestas por los jefes. Es 
necesario reconocer que el jefe es la directriz de una determinada área de 
acción, y que sus actividades no consisten en atender a los técnicos todo el 
tiempo. Éstos deben ser profesionales en sus actividades y hacer la parte 
¿que les corresponde; de lo contrario, abandone el puesto y permita que lo 
deupe alguien que verdaderamente quiera colaborar y formar parte activa 
de un mismo equipo, digno de aportar conocimientos y seriedad en su 
trabajo. 

3. Le sugiero continuar leyendo este libro, porque encontrará meto- 
dologías de trabajo afines al área de cómputo, las cuales no son empíricas 

or el contrario, cuentan con bases de estudio e investigación de varios 

Paos, Además, han sido implantadas en algunas instalaciones con resulta- 
dos exitosos. 

4. Una buena estrategia sería visitar instalaciones modelo donde exis 
tan metodologías y las respeten, así podrá comprobar los múltiples benefi 
cios que éstas arrojan. 


LEVADOR. 


No existen metodologías de trabajo; donde las hay, no se respetan. 
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Una metodología se puede definir como el conjunto de operaciones 
específicas que permiten conocer con acierto la manera y secuencia con la 
que deberá efectuarse un determinado trabajo. Es un hecho que todo tipo de 
trabajo requiere de una estrategia de pasos lógicos que conduzcan a produc- 
tos de alta calidad. A pesar de que en el ámbito computacional esto es un 
requisito inevitable, con frecuencia se viola esta regla. Muchas instalaciones 
no conocen los beneficios de una metodología. Otras, no pocas, lo entienden 
perfectamente bien, es más, cuentan con documentos excelentes en su con- 
tenido, pero están guardados y perfectamente resguardados, es decir, nadie 
los usa. Para todas ellas es conveniente que visiten instalaciones modelo don- 
de existan metodologías en operación, porque así podrán comprobar sus 
múltiples beneficios. 


14 


Elaboración de 
programas en la 
computadora 


Problema 


Se consume mucho Liempo máquina en la 
elaboración de los programas aplicativos y 
con frecuencia se tienen que hacer 
correcciones posteriores por no haber 
probado las condiciones predefinidas. 


Esto tiene que ver sin duda con la falta o deficiencia de procedimien- 
tos estándares para que un programa sea elaborado bajo estricto control 
de calidad y seguridad. Es frecuente que un programador inicie la elabo- 
ración de un programa partiendo de una definición verbal del analista o 
sólo de notas improvisadas derivadas de una plática informal entre ambos. 

Por ello es natural que el programador invierta gran parte de su tiem- 
po haciendo ajustes de última hora, que sumados a cada una delas etapas 
para la elaboración del programa, arrojan un lapso inconcebible; además, 
nunca se tiene la certeza de que en el programa fueron consideradas todas 
las posibles condiciones de proceso a que estará sujeto una vez terminado. 
Por lo tanto no es difícil suponer que cada programa hecho así, al ser 
sometido a una prueba integral del sistema, arroje resultados tan deficien- 
tes que obligan de nuevo a múltiples correcciones, incrementando aún 
más los tiempos. Finalmente, cuando por fin se dictamina que el sistema 
es factible de liberarse a producción, resulta un hecho que habrá fallas por 
inconsistencias, al operar bajo las rigurosas condiciones reales de los 
datos, los cuales superan con mucho a las condiciones triviales considera- 
das en la definición de los programas. 

Estos vicios son comunes en bastantes instalaciones; por lo tanto, la 
única posibilidad real de erradicarlos consiste en establecer etapas están- 
dares de trabajo que permitan ir midiendo la seguridad del trabajo y la 
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correcta utilización de los recursos de cómputo, así como la verdadera 
productividad de cada programador. Estas etapas se tienen que conside. 
rar en conjunto como una metodología que no sólo permita alcanzar un 
alto grado de confiabilidad en los resultados de cada programa, así como 
en la reducción de los tiempos para su elaboración, sino con el objetivo 
básico de implantar una disciplina en las labores de cada programador, 
Se verá que por sí sola cada etapa obliga a no pasar a la siguiente si no se 
ha cumplido rigurosamente con los objetivos establecidos para cada una 
de ellas. 


SUGERENCIAS DE SOLUCIÓN 


Un programa, para su elaboración, deberá pasar necesariamente por 
las siguientes etapas estándares: 

1. Elaboración de la definición del programa. El analista del sistema a que 
corresponde el programa tendrá que elaborar una definición escrita y estructu- 
rada, de tal manera que el programador asignado para la elaboración de dicho 
programa, cuente en forma completa con la documentación necesaria, la cual 
le indicará qué es lo que se quiere que haga el programa; cuáles son las entra- 
das; qué se desea como salidas; bajo qué condiciones se desean procesar los 
datos; bajo qué criterios de datos prucba se verificará la correcta operación del 
programa; qué cifras de control se requieren; y, en suma, cualquier descrip- 
ción necesaria para la correcta comprensión del programador. 

La documentación estructurada de la definición del programa deberá 
comprender lo siguiente: 


a) Hoja de orden de trabajo. Formaliza una solicitud de trabajo del + 
área de análisis y sistemas hacía el área de programación. 

b) Hoja del diagrama general de proceso. Esquematiza las entradas y 
salidas del programa, aludiendo directamente a los nombres de los 
archivos a procesar. Si el programa maneja varias opciones de pri 
ceso, entonces habrá una hoja de este tipo por cada opción a con: 
derar. Asimismo, también se hace mención de las longitudes de 
registros y factores de bloqueaje, además del método de acceso para 
cada archivo. 

e) Hoja de identificación y objetivos del programa. Esta hoja hará 
mención de la clave o nombre que se le dará a partir de este 
momento al programa. La clave o nombre deberá ser único para 
cada programa dentro del esquema total de los sistemas que Ile- 
guen a manejar. La documentación, mensajes del programa y cual- 
quier referencia al mismo deberán manejarse por esta clave o nom- 
bre. Asimismo, en la misma hoja se hará una descripción resumida 


h) 
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pero clara de los objetivos del proceso que tiene el programa dentro 
del contexto integral del sistema. 

Hoja de descripción de campos de registros de entrada. Esta hoja 
contiene el desglose detallado de los campos que contiene cada 
registro y las características individuales de cada uno. Si un archi- 
vo contiene diferentes tipos de registros, con un arreglo diferente 
de campos, habrá un desglose particular para cada tipo de registro. 
Se hará referencia al archivo correspondiente dentro de cada des- 
glose de cada registro. Aquí se hará mención de las longitudes de 
registros y factores de bloque correspondientes a cada archivo. Es 
conveniente que exista una nomenclatura estándar sobre los nom- 
bres de campos que componen a cada registro, lo cual permitirá el 
uso de estos mismos desgloses para otros programas que usen algu- 
no o varios de los archivos aqui definidos, abreviando codificación 
y desgloses varias veces. 

Hoja de descripción de campos de registro de salida. Esta hoja se 
debe sujetar a lo establecido en el punto anterior, sólo que en este 
caso es para archivos de salida 

Formatos de reportes impresos. Aquí se incluyen los formatos de 
impresión, donde se detallan las posiciones en las que se deberán 
imprimir encabezados, numeración de hoja, cantidades, etc. Asi- 
mismo, si existen diferentes tipos de impresión, habrá un formato 
por cada tipo a obtener. En caso de que las salidas de impresión 
sean formas preimpresas, se deberán anexar, de preferencia, mues- 
tras ejemplo llenas, a fin de que se considere dentro de la progra- 
mación una rutina de centrado de forma. 

Hoja de definición de tablas internas. Esta hoja hará mención de la 
longitud y cantidad de elementos de que consta la tabla, así como 
el contenido específico de cada uno de ellos. Por supuesto, la hoja 
sólo será requerida cuando se vayan a manejar este tipo de tablas. 

Hoja de criterios de datos prueba. El analista que desarrolle la defi- 
nición del programa es la persona más idónea para establecer los 
criterios de datos bajo los cuales se asegura que el programa cubrirá 
las condiciones a tratar cuando éste se encuentre en proceso real. 
Este aspecto nunca deberá dejarse al arbitrio del programador. 
Hoja de cifras de control. Aquí se deberá describir el formato de 
impresión, así como los conceptos y fórmulas matemáticas bajo las 
cuales deberán cuadrarse las cifras de control que certificarán, en 
parte, la correcta Función del programa. 

Hoja de descripción del proceso. Esta hoja es vital para lograr la 
correcta elaboración del programa. Aquí se deberá especificar “el 
qué” se quiere que haga el programa y no “el cómo”. Se deberá pre- 
cisar con claridad esta descripción logrando que se ajuste estricta- 
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mente al objetivo de tal programa. El analista deberá asistir al pro- 
gramador en cualquier duda o mala interpretación. De hecho 
deberá ser un requisito establecer una plática en la cual se precisen 
los objetivos del programa y se unifiquen conceptos entre ambos. 


2. Recepción de la definición en el área de programación. El área de 
análisis deberá enviar por escrito y perfectamente estructurada la defi- 
nición del programa hacia el área de programación, en donde la mesa 
de control verificará que dicha difinición contempla los requisitos 
establecidos. Si éstos no son cubiertos se deberá rechazar y regresar al 
área de análisis, puntualizando las razones que se argumentaron para 
la no aceptación. 

Si la definición está completa, la mesa de control la pasará al jefe o 
supervisor de programación para efectos de asignación. 

3. Estudio para la asignación del programa. Con base en las caracterís- 
ticas del programa en el área de programación, se determinará el nivel de 
programador al cual se deberá asignar. Para este caso se deberán conside» 
rar los siguientes niveles: 


a) Programador A (o supervisor), debe realizar programas con las 
siguientes caracterí 


+ Número de archivos de entrada, | o más. 

+ Combinación de condiciones a considerar, 4 o más. 

+ Número de archivos de salida, 1 o más. 

» Manejo de tablas internas de 1, 2 y 3 dimensiones. 

e Reportes con | o más acumulaciones y cortes, 1 o más. 
+ Elaboración de gráficas impresas o por terminal. 

+ Cualquier tipo de acceso de archivos. 

e Cualquier tipo de organización de datos. 

+ Manejo de opciones de programa, | o más. 

+ Manejo de rutinas externas (de usuario y de sistema operativo) 
+ Manejo de rutinas de cálculo. 

+ Cruce de archivos con o sin actualización de datos. 


b) Programador B, debe realizar programas con las siguientes caracte- 
rísticas: 


e Número de archivos de entrada, 1 o más. 

+ Combinación de condiciones a considerar, de 1 a 4. 
+» Número de archivos de salida, 1 o más. 

+ Manejo de tablas internas, de 1 y 2 dimensiones. 

+ Reportes con 1 a 4 acumulaciones y cortes, de 1 a 5. 
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+ Acceso secuencial y random por llave, parcial o completa, 
+ Organización secuencial e indexada. 

+ Manejo de opciones de programa, de 1 a 3. 

+ Manejo de rutinas externas (de usuario). 

* Manejo de rutinas de cálculo con operaciones simples. 

+ Cruce de archivos sin actualización de datos. 


e) Programador C (o en desarrollo), deberá realizar programas con las 
siguientes características: 


+ Número de archivos de entrada, 1 o 2. 
+ Combinación de condiciones a cor 
e Número de archivos de salida, 1 o 2. 

+ Manejo de tablas internas de una dimensión. 
+ Reportes sencillos (sin cortes). 

+ Acceso secuencial y random simple. 

+ Organización secuencial e indexada. 


rar, 102, 


Si no se quiere tener fechas desfasadas en la terminación de los pro- 
gramas, es necesario que la asignación de programa al nivel de programa- 
dor idóneo se tome muy en cuenta. Sin embargo, en ocasiones las cargas 
de trabajo originan que se asigne un programa complejo a un programa- 
dor cuyo nivel está por debajo del requerido. Si así sucediera será necesa- 
rio considerarlo en los calendarios de compromisos; también se requerirá 
que a tal programador lo asesore y supervise un programador de mayor 
nivel, porque de lo contrario se corre el riesgo de que el programador 
novato se empantane y se tenga que rehacer dicho programa. 

Por otro Taco, si se le asesora correctamente y el programa sale en 
tiempo por el énfasis que ponga el programador, se podrá considerar que 
éste se empieza a foguear para pasar a un nivel superior. 

4. Asignación de tiempo para la elaboración del programa. Esta fase es 
una de las más difíciles de establecer debido a la gran variedad de factores 
quese habrá de considerar. Sin embargo, será necesario marcar una fecha 
de compromiso, donde se tomen en cuenta factores de medición para 
determinarla con cierto grado de precisión. 

Para este caso, es bien sabido que las etapas que mayor tiempo consu- 
men a un programador son las de elaboración de diagrama de bloque, bajo 
el cual se esquematiza la solución lógica, incluyendo las pruebas de escri- 
torio necesarias y la codificación en el lenguaje de programación. 

Por ello, si consideramos los factores por los que se dedica mayor o 
menor tiempo a estas 2 etapas, podremos acercarnos con precisión al 
tiempo que tomará la elaboración de un programa determinado, 

El método consiste en descomponer en conceptos de detalle los ele- 
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mentos considerados en la definición del programa, y asignar tiempos 
apegados a la experiencia cotidiana. A modo de orientación se dan a con- 
siderar los siguientes parámetros, los cuales han arrojado fechas que se 
estiman cercanas a la realidad: 


a) Número de archivos de entrada. En realidad, el conocer el número 
de archivos de entrada que intervienen en un programa, por sí mis- 
mo, no da la idea de la complejidad inicial de un programa, ya que 
de alguna manera habrá que considerar estos archivos en la solu- 
ción lógica que se dé y en la codificación del programa. Esto consu- 
me tiempo, por lo cual se ha encontrado lo siguiente: 


Número de archivos Horas 
1 1 
2 2 
3 3 
4 4 
5 5 
b) Número de archivos de salida. De la misma manera, la cantidad de 


archivos que intervienen como salida representa un consumo de tiem- 
po; sin embargo, éste tiende a ser menor que en el caso de los archivos 
de entrada. La razón es que la solución lógica del programa atenderá 
coo nit al corte Lali, pato ple dora 

mente son producto del proceso considerado en las entradas. Los tiem- 

pos que se han encontrado son los siguientes: 


Número de archivos Minutos 
1 15 
2 30 
3 45 
4 60 


c) Número de campos a ser utilizados en los registros de entrada y 
salida. Este aspecto determina uno de los elementos más laboriosos 


SUGERENCIAS DE SOLUCIÓN 93 


tanto para el aspecto de la solución lógica como para el momento 
de codificar. Los tiempos analizados son los siguientes: 


Campos normales 


De A Horas Minutos 
1 30 o 45 
31 50 1 15 
51 100 2 30 
101 150 3 15 
151 200 4 00 
201 250 5 00 
251 300 6 00 
301 350 7 00 
351 400 8 00 


Campos empacados 


De A Horas Minutos 
1 5 0 30 

6 10 1 00 
1 20 1 30 
21 30 2 00 
31 40 2 30 
41 50 3 


d) Parámetros que recibe el programa para especificarle alguna fun- 
ción. Cuando un programa está sujeto a recibir parámetros, se 
deberá considerar que habrá que validarlos y, en su caso, enviar 
mensajes de error. Los tiempos encontrados son los siguientes: 


Número de campos Horas Minutos 


1 o 15 
2 o 30 


Número de campos Horas Minutos 
3 o 45 
4 1 00 
5 1 


e) Definición de tablas internas. Es evidente que la definición de tablas 
internas en programas requiere de tiempo, ya que se deberá tener 
mucho cuidado para llenarlas de datos, cuyo contenido deberá ser bien 
verificado, Los tiempos encontrados son como sigue: 


ExL=-M 
5 


En donde: 


E = Número de elementos que componen a la tabla. 
L = Longitud en caracteres de elementos, 
M = Tiempo requerido en minutos. 


Cantidad de operaciones aritméticas. Aquí se tomarán en cuenta 
las operaciones aritméticas que estén consideradas en el programa, 
incluyendo contadores de cualquier tipo. Para esto será necesario 
desglosar cualquier fórmula matemática en operaciones de detalle, 
Se consideran los siguientes tiempos: 


> 


De A Horas Minutos 

1 5 0 10 

6 10 0 20 

1 15 0 30 
20 0 40 


2) Manejo de rutinas de centrado de formas preimpresas. En impre- 
sión de formas preimpresas será conveniente elaborar rutinas que 
permitan hacer un centrado correcto de impresión para evitar rei- 
nicios y desperdicio de formas mal impresas. Los tiempos son: 
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Número Horas Minutos 
1 o 20 
2 o 40 
3 1 00 
4 1 


h) Manejo de rutinas de cortes. Si durante la impresión de reportes se 
tienen que efectuar cortes, esto también requerirá tiempo al pro- 
gramador. Los tiempos encontrados son: 


Número Horas Minutos 
1 0 20 
2 0 40 
3 1 00 
4 E 


20 


1) Depuración de contenido de campos. Cuando haya que verificar el 
contenido de campos, según ciertos criterios, los tiempos son: 


(Sminutos) x C = T 
En donde: 


C = Número de campos por depurar. 
T = Tiempo en minutos para la depuración. 


Rutinas para el manejo de tablas. Al respecto, además de tener que 
definir las tablas internas, el programador se verá obligado a desa- 
rrollar rutinas para el acceso a dichas tablas; por lo tanto, los tiem- 
pos establecidos para cada tabla considerada serán: 


Número Horas Minutos 


1 o 30 
2 1 00 
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m) 


Número Horas Minutos 
3 1 30 


Número de condiciones a considerar. Esto se refiere básicamente a 
Ja diversidad de tipos de registros que pueden venir en los archivos 
de entrada, ejemplo: considerar que en un mismo archivo vendrán 
registros tipo 1, 2, 3, y 40 1,3 y 40 3 y 4, etc. Es decir, todas las 
combinaciones posibles. Los tiempos a asignar son: 


Número Horas Minutos 
1 0 25 
2 o 50 
3 1 15 
s 1 40 


Constante de nivel de programador. Esta constante se aplica a fin 
de asignar un tiempo en el cual el programador analizará las distin- 
tas posibilidades bajo las cuales elaborará la solución lógica más 
apropiada para realizar un diagrama de bloque que produzca a su 
vez un programa ågil y de calidad. 


1 10 horas 
IB" 8 horas 
Nivel “A” 5 horas 


Esta constante podrá ser establecida con más precisión en cada ins- 
talación, de acuerdo con las características de los programas más 
comunes en dicha instalación. Asimismo, es posible que los tiem- 
pos señalados en los puntos mencionados anteriormente puedan 
variar de acuerdo con el criterio particular de cada instalación. 


Prueba de escritorio sobre el diagrama de bloque. Para este fin, el 
tiempo a asignar irá en función del tiempo total resultante de 
sumar los tiempos de los puntos 1 al 12, en cuyo caso se aumenta- 
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rán 10 minutos por cada hora resultante de la suma de los tiempos 

de los puntos 1 al 12. Este aumento de 10 minutos por cada hora 

sumada nos dará el tiempo requerido para la prueba de escritorio 
sobre el diagrama de bloque. 

Codificación del programa. Se considera que para codificar el pro- 

grama el tiempo requerido ya fue incluido en los tiempos resultan- 

tes de los puntos 1 al 12. 

Prueba de escritorio sobre la codificación. El procedimiento para 

obtener este tiempo es idéntico al inciso m, es decir, se aumentarán 

10 minutos por cada hora resultante en los puntos 1 al 12. 

Captación del programa ya codificado. Este tiempo será establecido por 

cada instalación, ya que depende básicamente de sus propios procedi- 

mientos establecidos para la captación de la codificación. 

4) Compilación y catalogación del programa. Al igual que el punto 
anterior, este tiempo será establecido en cada instalación. 

r) Prueba y depuración del programa. Este tiempo también está suje- 
to a cada instalación por la razón establecida en el inciso p. 

s) Validación de resultados de las pruebas. Para obtener este tiempo 
será necesario apegarse al criterio establecido en el inciso m. 

1) Documentación del programa. Para realizar las carpetas de progra- 
mación y operación no se establece tiempo, ya que los lapsos de 
espera de los puntos de captación, compilación, catalogación y 
prueba del programa son suficientes para elaborar tales carpetas. 


n) 


0) 


p) 


Al aplicar la técnica anterior para la asignación de tiempos se debe 
tener la certeza que se obtendrá una idea más apegada a la realidad, quesi 
sólo se asignara en forma empírica bajo apreciaciones intuitivas. 

En algunas instalaciones se ha pensado elaborar programas que al ser 
alimentados con los datos de detalle ya mencionados automáticamente 
obtienen el total de tiempo requerido para la elaboración de cualquier 
programa. 

5. Estudio para la elaboración del programa. Una vez seleccionado el 
programador cuyo nivel es el más apropiado para la elaboración del pro- 
grama, así como la determinación del tiempo requerido para su desarro- 
llo, dicho programador tendrá que realizar un estudio profundo sobre los 
criterios de la definición, hasta lograr una comprensión total. Requerirá 
auxiliarse por el analista que definió el programa para aclarar cualquier 
duda, por trivial que ésta sea. Esta fase es el fundamento principal para el 
desarrollo del programa, porque si se capta la idea clara de lo que se desea 
que haga el programa hasta en sus más mínimos detalles, por lo general, no 
existen problemas en la obtención de los resultados; y tal vez hasta se logre 
una solución óptima. Sin embargo, cuando se tienen dudas por parte del 
programador y éstas no son aclaradas con tiempo, invariablemente se llega- 
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rá a resultados erróneos, lo cual trae como consecuencia un uso indebido 
del computador, así como el despilfarro de horas hombre; además, lo más 
importante, se tendrán que alterar los planes para la integración de los pro- 
gramas que intervienen en el sistema y quizá no se pueda realizar una prue- 
ba completa de dicho sistema en los tiempos ya establecidos. 

6. Elaboración del diagrama de bloque. Si el programador ha captado 
completamente el planteamiento de la definición del programa y ya no 
existen dudas, se puede estar seguro que está preparado para desarrollar el 
diagrama de bloque que dé como resultado la solución lógica a tal plantea. 
miento. De lo contrario, no debe pasar a esta fase, ya que asumirá una 
gran cantidad de criterios no entendidos y obviamente no dará una 
correcta solución. 

Se debe establecer que todo programa, por sencillo que parezca, debe- 
rá primero ser resuelto mediante un diagrama de bloque, con lo cual se 
aseguré que en la solución lógica estan incluidos todos los factores que le 
darán los resultados esperados. 

Este diagrama deberá contener todos los detalles necesarios para diag- 
nosticar que no existen cabos sueltos, pero no se debe asumir nada, pues 
es frecuente encontrar diagramas de bloque con una apreciación muy 
general del problema a resolver. 

7. Prueba de escritorio sobre el diagrama. Una vez que se tiene el 
diagrama de bloque, éste debe ser sometido a una prueba de escritorio, 
la cual deberá ser lo más exhaustiva posible. Por supuesto, esta prueba 
debe realizarse de acuerdo con los criterios de datos prueba que previó 
el analista, y de cuyo resultado se obtendrán rigurosamente los resulta- 
dos ya predefinidos. No se podrá pasar a la siguiente fase si no se ha 
cumplido con lo anterior. 

8. Codificación del programa. Esta etapa es la que requiere de más 


atención, porque absorbe el cuidado del programador, ya que al transcri=- 


bir el diagrama en hojas de codificación se tendrá que cumplir con las 
variadas reglas de sintaxis requeridas por el lenguaje que se utilice, así 
como con los estándares establecidos por la propia instalación. 

La transcripción se debe hacer con mucho cuidado para que la codifi- 
cación contemple todo el planteamiento plasmado en el diagrama, ya que 
se debe entender que lo que se está haciendo es la transcripción de una 
solución encontrada, y no deberá omitirse ninguna consideración hecha: 
en el diagrama; o a la inversa, codificar rutinas que no están en el diagra- 
ma. Si esto ocurriera, se corre el riesgo de querer transcribir una solución 
incompleta. 

9. Prueba de escritorio sobre la codificación. Es frecuente que al trans- 
cribir el diagrama en instrucciones en forma involuntaria se omitan algu- 
nas consideraciones y se afecten los resultados finales. También, es 
común cometer errores de sintaxis que por lo general se encontrarán 
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cuando el programa sea compilado, perdiéndose tiempo inútilmente. Es 
por eso que de nuevo se requiere una prueba de escritorio, pero ahora 
sobre la codificación, lo cual aumenta la garantía de obtener resultados 
correctos en el computador; pero aun mediante esta segunda prueba es 
factible encontrar errores de lógica por algún descuido. 

10. Captación de la codificación. Cuando se esté completamente 
seguro de que tanto en el diagrama de bloque como en la codificación hay 
un alto grado de certeza para la obtención de resultados, es posible enviar 
las hojas de codificación para que se les haga la captación a medios proce- 
sables por el computador. Cada hoja codificada deberá apegarse cuando 
menos al siguiente esquema: 


+ Nombre o clave del programa. 

+ Nombre del programador. 

+ Fecha y hora. 

+ Número de hoja (1 de 10, 2 de 10, etc. 

+ Número de líneas codificadas por hoja. 

+ Número consecutivo de líneas (de 10 en 10 por posibles intercala- 
ciones). 


11, Verificación de la captación. Es probable que durante la captación 
se hayan cometido errores de dedo involuntarios, por lo que si dicha cap- 
tación se envía directamente a compilar habrá errores de sintaxis, lo cual 
representa un desperdicio de tiempo máquina. Para evitar esto es necesa- 
rio verificar lo captado línea por leer contra las hojas de codificación. 
Aunque es dificil, es posible que aún se encuentren errores de sintaxis u 
omisión de instruccciones que el propio programador haya cometido. 

12. Compilación y catalogación. Esta fase es la traducción del lengua- 
je fuente a lenguaje máquina, pero si existen errores de sintaxis no se rea- 
lizará la traducción y habrá tantas compilaciones como sean necesarias 
para lograr la depuración total. Esto obliga a que el computador sea utili- 
zado con frecuencia como depurador de errores, lo cual no es correcto 
bajo ningún pretexto. Por ello, si se ha seguido estrictamente la aplicación 
de las fases anteriores, se deberá entender queen un número no mayor a 3 
entradas a la máquina el programa estará depurado por completo listo 
para catalogarse. 

13. Transcripción de datos prueba. Una vez que se cuenta con los 
datos prueba codificados, los cuales han sido utilizados en las pruebas de 
escritorio, será necesario transcribirlos al medio en el cual serán probados 
en el computador. Es conveniente sacar listados de tales datos antes de 
iniciar las pruebas, y corroborar que éstos hayan sido captados en forma 
Correcta; de no ser así, las pruebas arrojarán resultados incorrectos y tal 
vez hasta el programa falle. 
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14. Prueba de depuración del programa en el computador. Esta fase es 
la que determina si hubo éxito o no en la elaboración del programa, por- 
que los resultados de todas las fases anteriores se pueden apreciar hasta 
este momento, y deberán ser estrictamente los que se predefinieron, en 
función de los criterios de datos prueba, 

Cuando se prueben varias opciones del mismo programa, es conve- 
niente armar un solo paquete que las incluya. De esta manera se obtienen 
rápidamente resultados con menos entradas a la máquina, que abrevia el 
tiempo requerido para esta fase, En este caso se considera normal hasta 3 
entradas al computador para fines de una depuración total. 

15. Validación de resultados. Una vez hechas las pruebas del progras 
ma, es indispensable validar los resultados hasta en sus más mínimos deta- 
lles, para poder afirmar que es un programa confiable; porque si bien en 
muchas ocasiones se cree que un programa trabajó correctamente con 
sólo verificar las cifras de control, se incurre en un grave error, ya que la 
verdadera verificación que garantiza resultados correctos se encuentra en 
la revisión detallada de los registros de salida, al comprobar que cada cam- 
po contiene información veraz; más aún, se deberá verificar el contenido 
de los campos que estuvieron sujetos a alguna operación y fueron actuali- 
zados. Asimismo, habrá que revisar acumulaciones, cortes, fechas, etc, 
Esta fase deberá ser estrictamente minuciosa, ya que de no ser así, puede 
originar que programas subsecuentes fallen en su proceso, a causa de 
malas salidas del anterior. 

16. Documentación del programa. La documentación completa y ade- 
cuada de un sistema programado que se desea implantar, mantener y 
actualizar en forma satisfactoria, es esencial en cualquier centro de 
cómputo; sin embargo, este requisito se descuida con frecuencia. La 
documentación es la herramienta que hace posible la operabilidad de los 
sistemas, aun sin la presencia de las personas que efectuaron los detalles, 
Es pues un fundamento histórico indispensable para lograr la contin: 
dad de los procesos, aunque exista rotación de personal 

Para documentar un programa elaborado basta con 2 carpetas, cuyo 
contenido se debe apegar cuando menos a lo siguiente: 


a) Carpeta de programación. Esta carpeta debe existir por cada pro- 
grama que interviene en el sistema, y su contenido debe aparecer 
en el siguiente orden: 


+ Diagrama general de proceso (uno por cada opción). 
+ Diseños de formatos de registros de entrada y salida. 
+ Diseños de impresión de reportes. 
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+ Explicaciones especiales. 

+ Listado de cláusulas de control para inicio y reinicio. 

e Listado del programa obtenido en la última compilación. 

+ Resultados de la última prueba del programa (listados de los 
archivos de entrada y salida obtenidos). 

+ Cifras de control de la última prueba. 


b) Carpeta de operación. Ésta debe ser un instructivo para la corrida 
del programa, cuyo contenido debe ser: 


+ Descripción del proceso. 

+ Diagrama general de proceso (uno por cada opción). 
plicaciones especiales para operación. 

+ Mensajes y acciones de operación, 

+ Descripción de formatos de parámetros. 

stado de cláusulas de control para inicio y reinicio. 
ormatos de registros de entrada y salida. 

+ Formatos de impresión. 

e Muestrario de cifras de control y fórmulas de verific: 


17. Entrega de la documentación, programa y cláusulas de control 
para inicio y reinicio. Una vez que se han cubierto todas las fases para la 
elaboración de cualquier programa, y los resultados de la última prueba 
hayan sido aprobados por el analista que lo definió, la carpeta de progra- 
mación será entregada al analista correspondiente para que pase a formar 
parte de la documentación completa del sistema. La carpeta de operación, 
el programa Fuente y las cláusulas de control para inicio y reinicio, serán 
entregadas al área de operación. 

Esta metodología ha sido adoptada por varias instalaciones y los resul- 
tados efectivos no se han hecho esperar; ya que se va guiando al programa- 
dor de manera que la mayor parte de su tiempo lo emplee en elaborar su 
plan de trabajo en el escritorio y de manera sistemática y ordenada, desa- 
rrollando actividades que garantizan casi siempre la obtención rápida de 
resultados correctos y confiables. En otras palabras, se obtiene del progra- 
mador una mayor productividad y se elimina al máximo el uso excesivo 
del computador. 
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Es frecuente que un programador inicie la elaboración de un progra- 
ma partiendo sólo de una definición verbal del analista. Debido a esto, es 
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natural que el programador invierta gran parte de su tiempo, además del 
desperdicio de tiempo máquina, haciendo ajustes de última hora. El pro- 
blema principal es que nunca se tiene la seguridad de que será un progra- 
ma confiable en producción. Estos vicios son comunes en muchas instala- 
ciones; por tanto, la única posibilidad real de erradicarlos consiste en 
establecer etapas estándares que permitan ir midiendo la seguridad del 
trabajo, así como la correcta utilización del computador. Se observará que 
por sí sola cada etapa obliga a no pasar a la siguiente si no se ha cumplido 
con el objetivo establecido para cada una. 


15 


Control de cambios 


Problema 


En la mayoría de los centros de 
cómputo, cuando falla algún programa, o se 
requiere un cambio necesario, se hacen 
reparaciones improvisadas y sin control. 


En todo sistema de información existe la posibilidad de realizar cam- 
bios, ya sea que éstos se originen por solicitud del usuario para obtener un 
nuevo resultado requerido por alguna necesidad de información, detecta- 
da hasta ese momento; por un cambio obligado por cuestiones legales; o 
simplemente para modificar o complementar el diseño de algún reporte 
de salida. Es decir, los sistemas por naturaleza deben ser dinámicos y con- 
gruentes con la necesidad de proyección de las instituciones. 

Asimismo, un cambio podría ser originado por programas deficientes 
que no fueron probados exhaustivamente y, puestos en producción, se 
llega a presentar alguna condición no prevista en el programa, originando 
una falla, 

Sin importar la manera como se ha originado un cambio, será necesa- 
rio que éste se sujete a un procedimiento estricto y no a reparaciones 
improvisadas y sin control, que lejos de ayudar, distorsionan la filosofía 
original del sistema, causando cada vez peores estragos en la producción; 
y lo que es peor, empieza a proliferar una dependencia casi absoluta de las 
personas que lo llevan a cabo. 

Actualmente esto se ha convertido en un vicio tan dañino que, pese al 
peligro que ocasiona, lo queremos ver como un mal necesario. Nos hemos 
acostumbrado a disfrazarlo como un problema obligado, sin entender que 
es una de las principales razones de los fracasos de un centro de cómputo. 

El pretexto frecuente es: “corríjase el problema y después veremos 
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qué hacer”, aunque todos sabemos que una vez resuelto el problema ya 
nada se hará. 


SUGERENCIAS DE SOLUCIÓN 


1. Es necesario establecer que existen 2 tipos de cambios: temporales y 
permanentes. 

2. Los cambios temporales se identifican porque sólo afectan a la corrida 
circunstancial de un proceso; es decir, que después de haber cumplido 
con el proceso, dicho cambio desaparece, como si nunca hubiera existi- 
do. Por eso no es necesario establecer un control tan estricto; sin 
embargo, tales cambios se deben sujetar a lo siguiente: 


a) Si el cambio afecta únicamente a claúsulas de control o a paráme- 
tros, aun así dicho cambio nunca se deberá hacer directamente en 
los archivos oficiales de producción, sino que tales elementos 
deberán ser copiados a archivos en forma alternada y ahí es donde 
se hará el cambio y la corrida del proceso, después de lo cual estos 
archivos deberán borrarse para no caer en confusiones futuras, 

b) Si el cambio es hacia programas, del mismo modo se deberá efec- 
tuar el cambio en bibliotecas alternas, y de ahí se tomarán para 
efectuar la corrida; después de realizada ésta, los programas corres- 

fadientes tendón. que ser respaldados cos fecha de coducided 
Frailes de las bibliotecas alternas. 


3, Los cambios permanentes se identifican porque permanecerán para un 
futuro o para un lapso considerable. Por esto, tales cambios tendrán 
que sujetarse a un procedimiento estricto. Los pasos a seguir serán los 
siguientes: 


a) Antes de hacer el cambio en forma permanente, éste deberá reali- 
zarse en primer orden como si fuera un cambio temporal; es decir, 
llevarlo a cabo en archivos o bibliotecas alternas a las oficiales de 
producción. 

b) Realizar el cambio según la definición, procurando que ésta esté 
por escrito. 

e) Una vez hecho el cambio en archivos o bibliotecas alternas, se pro- 
cede a efectuar las pruebas necesarias y se obtienen los resultados 
con el cambio reflejado. 

d) Teniendo todos los elementos para comprobar que dicho cambio 
se ha realizado satisfactoriamente, se pracede a pasar a la fase de 
autorización donde la persona facultada para autorizar deberá ser 


e) 


8) 
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el analista que definió dicho cambio. A él se le entregarán todos los 
elementos de la última prueba para que se percate de que el cambio 
ha sido cubierto en todos sus detalles. Es necesario amparar este 
control con una forma similar a la que se anexa más adelante. 
Una vez autorizado el cambio, se procede a la afectación de los 
archivos y bibliotecas oficiales de producción, a fin de reflejar el 
cambio en forma permanente. 

Hecho lo anterior , se efectuará una última prueba en este medio; pre- 
sentando las carpetas de documentación actualizadas con el cambio, 
se volverá a pasar con el analista que autorizó éste para confirmar que 
el mismo es permanente y seguro para procesos reales. 
Valiéndose de la forma de control, el ciclo de cambio quedará 
cerrado al estampar la segunda firma de aceptación y autorización. 
Esta forma será la evidencia oficial de que el cambio se efectuó bajo 
riguroso control. 


Las características de la forma son las siguientes: 


CONTROL DE CAMBIOS 
Se ofectúa cambio a: 
Programa fuente O Cláusulas de control O 
Parámetros © Otros (especificar): 
El cambio será: 
Temporal: E] Permanente C 


Nombre del sistema o aplicación: 


Nombre de elemento(s) a afectar: — 


Descripción del cambio: 


Nombre de quien efectuó el cambio: ———— 


Hora: 


Fecha: 


Nombre de quien autorizó et cambio: ——— 


Hora: 


Firma de autorización: 


Fecha: 


1506 
AUTORIZACIÓN DEFINITIVA 


Carpeta donde quedó documentado el cambio: 

Hora: Fecha: 
Firma de autorización definitiva: 
Comentarios: 
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En todo sistema de información existe la posibilidad de realizar cambios, 
ya sea que éstos se originen por el usuario al requerir un nuevo resultado; pue- 
den ser motivados por efectos legales o por otras razones; es decir, los sistemas 
por naturaleza no pueden ser estáticos, Sin importar la manera como se origi- 
ne un cambio será necesario que éstos se sujeten a un procesamiento estricto. 
Jamás deben permitirse reparaciones improvisadas, ya que éstas distorsionan la 
filosofía original del sistema y normalmente no queda registro. El pretexto fre- 
cuente es: “corríjase el problema y después veremos qué hacer”. Sabemos que 
una vez resuelto el problema nada se hará. Se deben identificar dos tipos de 
cambios: temporales y permanentes. Cualquiera que sea éste, deberá contro- 
larse estrictamente. 


16 
Administración de 
archivos 


Problema 


Gran parte de los centros de cómputo 
tienen problemas con el control de los 
archivos de datos que se resguardan. 


Existen varios factores por los que una instalación pierde el control 
en cuanto a cantidad, contenido, tipo e importancia de los archivos de 
datos que mantiene en resguardo. Esto se antoja inconcebible en un cen- 
tro de cómputo cuya función es precisamente esa. Así, los desajustes más 
severos que enfrentan tales instalaciones son: 


1. Procesos erróneos al encontrar que se manejaron archivos equi- 
vocados. 

2. Pérdidas elevadas en tiempo máquina y de operación. 

Resultados incorrectos encontrados hasta que el usuario los 

detecta. 

4. Pérdidas cuantiosas en impresión con datos erróneos tanto en 

formas preimpresas como papel stock. 

Saturación de paquetes de discos y cintas con archivos obsoletos. 

6. Consulta errónea y actualización de archivos maestros afectados 
con archivos inválidos. 

7. Severas dificultades al tratar de restaurar archivos maestros mal 
actualizados. 

8. Extravíos frecuentes de datos valiosos e históricos. 

9. Destrucción de archivos útiles. 

10. Necesidad de trabajos urgentes a deshoras y fines de semanas a fin 
de reestructurar archivos mal actualizados o perdidos. 

L1. Demoras frecuentes en la entrega de resultados. 
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12. Confusión para identificar a qué áreas o 
los archivos resguardados. 

13. Sistemas descontinuados al perder archivos medulares de difícil 
recuperación. 

14. Alto grado de posibil 
archivos. 

15. Poca confidencialidad de archivos con datos restringidos. 


emas corresponden 


lidad de alteraciones fraudulentas en los 


Estos puntos no abarcan las consecuencias que originan el descontrol 
ya mencionado, pues es imposible saber a ciencia cierta cuántos proble. 
mas se presentan a diario en instalaciones con tal situación. Es increíble 
que esto suceda en no pocas instalaciones del país. Da la impresión de que 
ahí no trabajan profesionales del ramo. 

Este problema atañe directamente a los jefes que permiten que el cen- 
tro de cómputo se les desintegre en las manos. Son jefes que no saben 
poner orden debido al desconocimiento, no de lo que deberían hacer sino 
del riesgo tan alto que esto ocasiona. 

Nose pretende que sean especialistas de todas las actividades nece- 
sarias de la instalación, sino que tengan la suficiente experiencia para 
detectar anomalías y establecer correctivos oportunos; que sepan dôn- 
de están ubicados, cuáles son sus responsabilidades y funciones y pue- 
dan valorar los riesgos de los malos procedimientos detectados y no se 
atemoricen ante las adversidades. Deben entender que los técnicos 
están a expensas de lo que ellos vislumbren y determinen para un 
correcto desempeño. 


SUGERENCIAS DE SOLUCIÓN 


1. El primer facto, que se debe establecer para abordar el problema de 
la falta de control de los archivos de datos, es clasificar el tipo de datos con 
los que el centro opera, y establecer un esquema por orden de importan- 
cia. Esto podría ser como sigue: 


+ Archivos de producción. 

+ Archivos para prueba de sistemas integrales. 
+ Archivos del sistema operativo en operación. 
« Archivos del sistema operativo en prueba. 

e Archivos para desarrollo de nuevos sistemas. 


2. Una vez clarificado el tipo de archivos y su importancia, se estable- 
cerá una identificación muy precisa para determinar los esquemas de res- 
paldo para aquellos archivos vitales, históricos o de difícil recuperación. 
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+ Resguardo local. 
+ Resguardo fuera de sitio. 


Los archivos con resguardo local son aquellos que por la naturaleza de 
los procesos de la instalación deben estar disponibles en el momento 
oportuno para la producción diaria. Se debe tener el cuidado de que estos 
archivos siempre tengan sus respaldos, ya sea ubicados localmente o fuera 
de sitio, sobre todo los que son actualizados con frecuencia. No hay que 
olvidar obtener respaldo también de los archivos de movimiento con los 
cuales fueron afectados los primeros. 

Los archivos con resguardo fuera de sitio serán aquellos que por su 
importancia en la historia de la instalación sean vitales en casos de pérdi- 
das o daños de los archivos locales para restablecer cualquier accidente y 
que se puedan reponer rápidamente. Estos archivos deberán estar en una 
bóveda contra accidentes, fuera y distante del centro de cómputo donde 
se mantengan los respaldos necesarios para proteger cualquier desastre, 
En esta bóveda deberán resguardarse básicamente: archivos maestros, 
archivos históricos y archivos de difícil recuperación. 

Esto deberá ser un aspecto respetado por todo centro de cómputo, 
no importa si es grande o pequeño, pues ninguna instalación está 
exenta de actos de terrorismo, accidentes, o robos. Son posibilidades 
Intentes que tienen que ser cubiertas. Véase como seguro de vida, don- 
de no se sabe cuándo pueda ocurrir un accidente, ni cómo, pero llega- 
rá; es entonces cuando habrá que estar preparado. Además el costo de 
prevenir los daños a los archivos es raquítico si lo comparamos con los 
beneficios que esto significa. 

El manejo de fechas de caducidad también es muy importante; esto 
ayudará a resguardar y mantener sólo archivos útiles y activos, para elimi- 
nar así confusiones peligrosas que indujeran a dar de baja archivos nece- 
sarios o saturar los medios de almacenamiento con archivos obsoletos que 
tienden a confundir el ambiente. 

Con un esquema de Fechas de caducidad, los procesos automáticos o 
manuales para depurar son muy seguros y rápidos. 

La identificación individual de cada archivo es el punto débil si no se 
planea en forma eficiente; es decir, la consistencia, seguridad y asigna- 
ción de una nomenclatura moderada pero segura, por sí sola debe contes- 
tar las siguientes preguntas 


+ ¿Qué archivo es? 

A quién corresponde? 

+ ¿Qué tipo de archivo es? 

+¿En dónde se encuentra dicho archivo? 
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Como una orientación, a continuación se dan modelos de nomencla- 
tura que permiten operar con un alto grado de seguridad en cualquier 
centro de cómputo. Sigala, imítela, adáptela, analicela, implántela o com- 
pleméntela; pero haga algo para corregir el problema mencionado. 


FORMATO DE NOMENCLATURA PARA 
LA FORMACIÓN DE GRUPOS DE ACCESO 


Descripción: 


Dentro del esquema de seguridad para protección de los datos contenidos en los archi 
vos concentrados en un centro de cómputo se ha determinado el concepto de grupos de acce- 
so por unidad usuaria. 

Una unidad usuaria se define como el área dentro de la organización que cubre una fun» 
ción completa y casi autónoma, 

Lo anterior quiere decir que los archivos que pertenecen a una determinada unidad 
usuaria no podrán ser aceesados por otra. Es decir, los procesos de consulta y afectación de 
esos datos serán por efecto de los sistemas de cada unidad. 


Para este caso, los grupos de acceso abarcarán los siguientes tipos de archivos: 


«+ Bibliotecas (archivos particionados). 
+ Archivos secuenciales. 

+ Archivos secuenciales-indexados. 
+ Archivos directos. 

+ Archivos VSAM “ESDS'. 

+ Archivos VSAM “K8DS', 

+ Paths alternos VSAM “KSDS'. 

+ Bases de datos. 

+ Archivos del sistema operativo, 
+SYS1 

+SYS2, 


Los grupos de acceso significarán a su vez el primer calificador de los nombres de archi= 
vo como sigue: 


=== Nombres de grupos de acceso =====| 


"Nombres de archivos. Nombres de bibliotecas 


A a BERRRRRS - XA + A 
(ler. Calif) (ler. Calit) 


FORMATO DE NOMENCLATURA PARA LA 
FORMACIÓN DE GRUPOS DE ACCESO 
PARA BIBLIOTECAS 


Para bibliotecas de uso general dentro de una unidad usuaria. 


——» 'GRAL' = Constante (uso general. 
Constante (biblioteca). 

L- U ~ Constante (unidad). 
uu = Clave de unidad usuaria. 


> 


Para bibliotecas de uso exclusivo de un área dentro de la unidad. 


L --»'B' = Constante (biblioteca). 
Clave de área dentro de la unidad. 


a 7 
l i 1 
| i li 


FORMATO DE NOMENCLATURA PARA LA 
FORMACIÓN DE GRUPOS DE ACCESO PARA 
ARCHIVOS SECUENCIALES 


Para archivos secuenciales de uso general dentro de una unidad usuaria. 


[i Le GRAL' = Constante (uso general). 

i —»'S = Constante (archivo no VSAM-secuenciales). 
i Lp U = Constante (unidad). 

Lp uu = Clave de unidad usuaria. 
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Para archivos secuenciales de uso exclusivo de un área dentro de la unidad. 


L'S’ = Constante (archivo no VSAM-secuenciales) 
Clave de área dentro de la unidad. 
E Wu = Clave de unidad usuaria. 


FORMATO DE NOMENCLATURA PARA LA 
FORMACIÓN DE GRUPOS DE ACCESO PARA 
ARCHIVOS SECUENCIALES-INDEXADOS 


Para archivos secuenciales 


'xados de uso general dentro de una unidad usuaria. 


i 

i Ly T = Constante (archivo secuencial=indexado). 
i -p 4 = Clave de área dentro de la unidad. 

Lp uu = Clave de unidad usuaria. 


FORMATO DE NOMENCLATURA PARA LA 
FORMACIÓN DE GRUPOS DE ACCESO PARA 
ARCHIVOS NO VSAM DIRECTOS 

Para archivos directos de uso general dentro de una unidad usuaria. 


A continuación se describen los estándares de nomenclatura para estructurar los nom- 
bres de los grupos de acceso. en función del tipo de archivo de que se trate. 


1 ——» "GRAL = Constante (uso general). 
1 —» D" - Constante (archivo directo). 

L- U — Constante (unidad). 

44 = Clave de unidad usuaria. 


i 
i 


Para archivos directos de uso exclusivo de un área dentro de la unidad. 


L--» 'D' = Constante (archivo directo). 
a = Clave de área dentro de la unidad. 


FORMATO DE NOMENCLATURA PARA LA 
FORMACIÓN DE GRUPOS DE ACCESO 
PARA ARCHIVOS VSAM ‘ESDS’ 


Para archivos VSAM 'ESDS' de uso general dentro de una unidad usuaria, 


1 
i-p 'U' = Constante (unidad). 
p wu = Clave de unidad usuaria. 


Para archivos VSAM 'ESDS' de uso exclusivo de un área dentro de la unidad 


—-» E = Constante (archivo VSAM “ESOS 
Clave de área dentro de la unidad. 
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FORMATO DE NOMENCLATURA PARA LA 
FORMACIÓN DE GRUPOS DE ACCESO PARA 
ARCHIVOS VSAM ‘KSDS’ 


Para archivos VSAM “KSDS' de uso general dentro de una unidad usuaria. 


L- p "GRAL; = Constante (uso general) 
L- 'K' = Constante (archivo VSAM 'KSDS). 

E -p 'U' = Constante (unidad). l 
—-» uu = Clave de unidad usuaria. 


Para archivos VSAM 'KSDS' de uso exclusivo de un área dentro de la unidad. 


-+ K = Constante (archivo VSAM “KSDS). 
llave de área dentro de la unidad, 


FORMATO DE NOMENCLATURA 
PARA LA FORMACIÓN DE 
GRUPOS DE ACCESO 

PARA ARCHIVOS 

ALTERNOS ‘KSDS’ 


Para paths alternos VSAM 'KSDS' de uso general dentro de una unidad usuaria. 


— GRAL’ - Constante (uso general) 
—» 'P - Constante (path alterno VSAM ‘KSDS’, | 
Constante (unidad). 
e de unidad usuaria. 
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Para paths alternos VSAM “KSDS' de uso exclusivo de un área dentro de la unidad. 


L_ "P" = Constante (Path alterno VSAM 'KSDS”, 
-+ 2 = Clave de área dentro de la unidad. 
y Un = Clave de unidad usuaria. 


FORMATO DE NOMENCLATURA 
PARA LA FORMACIÓN DE 
GRUPOS DE ACCESO 

PARA BASES DE DATOS 


Para bases de datos de uso general dentro de una unidad usua 


f 
i L-e GRAL = Constante (uso general). 
L- -p 'X' = Constante (bases de datos). 

Lp 'U' = Constante (unidad). 


i Lp 'X = Constante (base de datos). 
L- —p a — Clave de área dentro de la unidad. 
—- uu = Clave de unidad usuaria. 
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FORMATO DE NOMENCLATURA 
PARA LA FORMACIÓN DE 
GRUPOS DE ACCESO PARA 
BASES DE DATOS CON 
INFORMACIÓN 

DE DIRECCIÓN 


Lp "X" = Constante (bases de datos). 
¡ L_ p D = Constante (dirección). 
4 uu = Clave de unidad usuaria. 


FORMATO DE NOMENCLATURA 
PARA LA FORMACIÓN DE 
GRUPOS DE ACCESO 

PARA ARCHIVOS DE 

USO UNIVERSAL 


Para bibliotecas de uso universal. 


-+ 8 = Constante (biblioteca). 
tante (uso universal) 


—-» ‘S’ = Constante (archivo secuencial) 
= Constante (uso universal) 


Para archivos secuenciales indexados de uso universal 
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"T = Constante (archivo secuencial indexado). 


-- -p 'D' = Constante (archivo directo). 
-e UU = Constante (uso universa). 


Para archivos VSAM ‘ESDS’ de uso universal. 


— E = Constante (archivo VSAM 'ESDS'). 
nte (uso universal). 


Para archivos VSAM ‘KSDS de uso universal. 


~- -p 'K' = Constante (archivo VSAM 'KSDS'). 
Constante wso universal). 


——» Y = Constante (bases de datos). 
Constante (uso universal). 
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FORMATO DE NOMENCLATURA PARA 
LA FORMACION DE LOS NOMBRES 
DE ARCHIVOS DE DATOS 


Descripción: 


Todo archivo ubicado dentro del centro de cómputo deberá estar identificado con un 
nombre único. Esta regla es de carácter obligatorio en dicho ambiente, 

Con este fin, y para lograr una identificación rápida que permita, por medio de su nombre- 
(DSNAME). conocer a quién pertenece, cuál es su contenido, y así evitar la duplicidad de nom- 
bres; a continuación se describen las reglas estándares de codificación: 


FORMATO DE NOMENCLATURA PARA 
LA FORMACIÓN DEL NOMBRE (DSNAME) 
INDIVIDUAL PARA ARCHIVOS 


Para archivos comunes de sistemas aplicativos en la fase de prueba y en servicio. 


H ~- GnnnnVmn = Para ver 
siones de archivos h 

L- ~ -a MIMI! = Identificación de la función básica 

del archivo. 

i -» $88 = Identificación del sistema y subsistema, 

L-e 'SV' = Constante (archivo en servicio). 

L---» 'PRU' = Constante (archivo para pruebas) 


En donde: 


HIT = La identificación de la función básica de este archivo (ejem: MOVIM será para 
determinar que es un archivo de movimientos) hacia un archivo macstro, 
Sss = En formato libre codificar la clave del sistema y subsistema de que se trate, 
teniendo cuidado de asignar la misma para el mismo sistema y subsistema. 
egegeges = Para efectos de poder codificar el nombre de grupo de acceso / 


Para archivos comunes de sistemas aplicativos en la fase de prueba en estado de 
respaldo. 


ia 


F Ter. Cali 


GananVan + 


OPCIONAL? 

! + GnnnnVnn = Para ver- 
H siones de archivos histó 
L -p MMT = Identificación de la función básica 
i del archivo. 

L- Sss = Identificación del sistema y subsistema. 

-p BK = Constante (archivo en respaldo). 

U'= Constante (archivo para pruebas). 


En donde: 


mmt = La identificación de la función básica de este archivo (ejem: MOVIM será para 
determinar que es un archivo de movimientos) hacía un archivo maestro. 

Sss = En formato libre codificar la clave del sistema y subsistema de que se trate, 

teniendo cuidado de asignar la misma para el mismo sistema y subsistema. 


gegeeggg = Para electos de poder codificar el nombre de grupo de acceso. 


Para archivos comunes de sistemas aplicativos en la fase de producción y en servicio, 


} ter. Calif. § 240. Calif. 


| eegegeeg | 'OPC' ¡"SY 


Fo OPCIONAL?" 

L- GnnnnVnn = Para ver- 
siones de archivos hist 

L -p MTI = Identificación de la función básica 
del archivo. 

L-e S38 = Identificación del sistema y subsistema. 

SV = Constante (archivo en servicio). 

-—» 'OFC' = Constante (archivo oficial de producción). 

L-e egeggeee = Nombre de grupo de acceso. 


En donde: 


mmt = La identificación de la función básica de este archivo (ejem: MOVIM será para 
determinar que es un archivo de movimientos) hacia un archivo maestro. 
Sss — En formato libre codificar la clave del sistema y subsistema de que se trate, 
teniendo cuidado de asignar la misma para el mismo sistema y subsistema. 
egegegeg = Para efectos de poder codificar el nombre de grupo de acceso. 
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MMT = La identificación de la función básica de este archivo (ejem: MOVIM será para 
determinar que es un archivo de movimientos) hacia un archivo maestro. 
Sss = En formato libre codificar la clave del sistema y subsistema de que se trate, 
teniendo cuidado de asignar la misma para el mismo sistema y subsistema, 
Seeseges = Para efectos de poder codificar el nombre de grupo de acceso. 


i GnnnnVnn 
T R **OPCIONAL** 
! L- GnnnnVnn = Para vé 
1 siones de archivos 
i L- MITA = Identificación de la función E 
H del archivo. 
h ~+ S53 = Identificación del sistema y subsistema, 
i L- -p 'BK' = Constante (archivo en respaldo). l 
i LL» 'OFC' = Constante (archivo oficial de producción) 
L ~-e BegBeggg = Nombre de grupo de acceso. 
En don 


FORMATO DE NOMENCLATURA 
PARA LA FORMACION DE LA 
IDENTIFICACION INDIVIDUAL 


Descripción 


Toda persona que requiera del uso de los recursos de cómputo deberá estar reconocido 
por una clave individual de usuario denominada como USERID. 

Sin esta clave, no será posible la autorización para acceso al uso del equipo de cómputo 
para ninguna persona. ya que de manera completamente automática, cuando se intente su 
lso, la persona será requerida para que proporcione su clave individual (USERID), y sólo 
cuando la clave proporcionada sea válida se autorizará el acceso. 

Para que una persona sea autorizada, será necesario que quede registrada por medio de 
¡su identificación individual (USERID) dentro de los archivos de seguridad controlados por el 
sistema operativo. Por lo tanto, es requisito solicitar su aha al personal del grupo de soporte 
técnico, 

En el caso del esquema de nomenclatura, esta clave representará el primer calificador 
para los nombres de bibliotecas privadas para cada programador. 

Las reglas para la formación del USERID para cada persona se enmarcan a continuación: 
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FORMATO DE NOMENCLATURA PARA LA 
FORMACIÓN DE LA CLAVE DE IDENTIFICACIÓN 
PERSONAL (USERID) 


=p XXX = Iniciales del nombre de la persona. 


Ly a - Clave de área dentro de la unidad. 


L -p Uu = Clave de unidad usuaria. 


A continuación, se presentan los distintos niveles de autorización, con el fin de estructu- 
rar cada USERID. 


Tabla para la asignación de niveles de autorización para el personal de 
las unidades usuarias externas al centro de cómputo, 


Nivel de 
autorización Descripción 


Este nivel de autorización deberá ser asignado a perso- 
$ nas cuyo trabajo consista en operar la información de 
2 sistemas ya desarrollados con posibilidades de accesar 

sólo archivos y pueden incluso alterar su contenido. 


Este nivel de autorización deberá ser asignado a perso- 
nas cuyo trabajo consista en operar la información de 

3 sistemas ya desarrollados con posibilidades de accesar 
sólo archivos, para efectos únicamente de consulta de 
datos. 


Nota: Para este caso, el nivel de auociación lo único que tipifica es el trabajo que e realiza, mas no la jerar. 
ia 0 el nivel de conocimientos de la persona 


Tabla para la asignación de niveles de autorización para el personal del 
centro de cómputo. 


Nivel de 
Autorización Descripción 


Este nivel de autorización deberá ser asignado al personal 
propio de soporte técnico, el cual tiene la responsabilidad 

0 de dar mantenimiento a los programas, parámetros y 
archivos del sistema operativo. 
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(Continuación) 


Nivel de 
Autorización Descripción 


Este nivel de autorización deberá ser asignado al personal 
1 de desarrollo de sistemas, el cual tiene la responsabilidad 
de dar mantenimiento y soporte aplicativo. 


Este nivel de autorización deberá ser asignado al personal 
2 que realiza básicamente funciones de programación y 
operación de procesos. 


Este nivel de autorización deberá ser asignado al personal 
3 en entrenamiento, incluso a operadores de la computado- 
ra que lo justifiquen por sus funciones. 


FORMATO DE NOMENCLATURA PARA LA 
FORMACIÓN DE BIBLIOTECAS 


Descripción: 


Toda biblioteca ubicada dentro de los dispositivos de almacenamiento, deberá estar: 
identificada con un nombre único. Esta regla es de carácter obligatorio. requerida por el pro- 
plo sistema operativo. 

Con este fin, y para lograr una identificación rápida que permita, por medio de su nombre 
(DSNAME), conocer a quién pertenece, cuál es su contenido así como evitar la duplicidad de 
nombres, a continuación se describen las reglas estándares de codificación 

Para bibliotecas privadas personales para programadores, 


2do Catit. 


'SPRIVLIB' 


-p tutut = Tipo de biblioteca. 

—» 'SPRIVLIB' — Constante (biblioteca de uso personal 
en servicio). 

—-— wwuuuu = Identificación personal (USERID). 


En donde: 


tus -= El tipo de biblioteca para este caso podrá ser únicamente de los dos tipos 
siguientes: 


— Fuente 
— Carga 
usuuuna = Identificación personal. 
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Para bibliotecas privadas personales en estado de backup para programadores. 


Pp 


siguientes: 


numa = Identificación personal. 
Para bibliotecas comunes de sistemas aplicativos en la fase de prueba y en servicho. 


ter, Calit. 260. Calit. 


j Lp unuu = Tipo de biblioteca. 
—» 588 = Identificación del sistema y subsistema. 
Lose Constante (biblioteca en servicio), 
PRU" = Constante (biblioteca para pruebas). 
_, Gaspar = Nombre de grupo de acceso. 


En donde: 
ittttttt = El tipo de biblioteca para este caso podrá ser únicamente de los siguientes 
tipos: 
— Fuente = JCLdisp = Proced — Carga 
— Macros — Params — Objeto = Gráficas 
= Clists — Menús ~ Estand = JCLstrue 


Sss = En formato libre codificar la clave del sistema y subsistema de que se trate, 
teniendo cuidado de asignar la misma para el mismo sistema y subsistema. 
gescegsa = Para efectos de poder codificar el nombre de grupo de acceso. 


Para bibliotecas comunes de sistemas aplicativos en la fase de prueba en estado de 
backup. 


: — HUA = Tipo de biblioteca. 

L p Sas = Identificación del sistema y subsistema. 
1 Lo "BK'= Constante (biblioteca en backup) 

Ls PRU = Constante (biblioteca para pruebas). 


En donde: 


wte = 


Sss = 
AS 


El tipo de biblioteca para este caso podrá ser únicamente de los siguientes 
tipos: 


= Fuente - JCLdisp — Proced - Carga 
— Macros = Params - Objeto - Gráficas 
- Clists — Menús - Estand - JCstruo 


En formato libre codificar la clave del sistema y subsistema de que se trate, 
teniendo cuidado de asignar la misma para el mismo sistema y subsistema. 
Para electos de poder codificar el nombre de grupo de noceso. 


Para bibliotecas comunes de sistemas aplicativos en la fase de producción y en servicio. 


! L e Max = Tipo de biblioteca. 
L _, Sss — Identificación del sistema y subsistema. 
i Lp 'SV" = Constante (biblioteca en servico). 
OFC = Comstate(lloeca octal de producción, 


En donde: 


wuu = 


Sss = 


segesege = 


El tipo de biblioteca para este caso podrá ser únicamente de los siguientes 
tipos: 


— Fuente - JCldisp - Proced - Carga 
— Macros — Params - Objeto — Gráficas 
- lists — Menús - Estand — JOlstruo 


En formato libre codificar la clave del sistema y subsistema de que se trate. 
teniendo cuidado de asignar la misma para el mismo sistema y subsistema, 
Para efectos de poder codificar el nombre de grupo de acceso. 
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Para bibliotecas comunes de sistemas aplicativos en la fase de producción en estado de 


L-, Sss = Identificación del sistema y subsistema. 


II e n 
j L-e BK" = Constante (biblioteca en backup). 


En donde: 
muutt = El tipo de biblioteca para este caso podrá ser únicamente de los siguientes 
tipos: 
- Fuente — JCLaisp — Proced - Carga 
— Macros — Params = Objeto Gráfic 
- Ciists — Menús = Estand JClstruc 


Sss = En formato libre codificar la clave del sistema y subsistema de que se trate, 
teniendo cuidado de asignar la misma para el mismo sistema y subsistema. 
sesseges = Para efectos de poder codificar el nombre de grupo de acceso. 


Para bibliotecas comunes de programas producto (software de apoyo al sistema operati- 
vo) en la fase de pruebas. 


H L p Hutt = Tipo de biblioteca. 

| Lp axx = Identificación del programa producto. 
L» PR" = Constante (biblioteca en pruebas). 

L-e PPS' = Constante (biblioteca de programa producto). 


En donde: 

tittttit = El tipo de biblioteca para este caso podrá ser únicamente de los siguientes 
tipos: 
— Fuente - JOLdisp — Proced - Carga 
— Macros — Params — Objeto - Gráficas 


- Ciists — Menús. — Docum — JCLstruc 
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xxx = En formato libre codificar la clave del programa producto de que se trate. 
geegeege = Para electos de poder codificar el nombre de grupo de acceso. 


Para bibliotecas comunes de programas producto (software de apoyo al sistema operati= 
vo) la fase de servicio. 


l i Le uutuu = Tipo de biblioteca, 
1 Ly xxx = Identificación del programa producto. 
Le SV = Constante (biblioteca en servicio) 

Le PPS’ = Constante (biblioteca de programa producto). 
—» eeegegge = Nombre de grupo de acceso. 


En donde: 
tua = El tipo de biblioteca para este caso podrá ser únicamente de los siguientes 


tipos: 

- Fuente = JCLdisp — Proced — Carga. 

— Macros = Params — Objeto - Gráficas 

= cists — Menús. = Docum = Ilate 


xxx = En formato libre codificar la clave del programa producto de que se trate. 
asusasgs = Para efectos de poder codificar el nombre de grupo de acceso. 


Para bibliotecas comunes de programas producto software de apoyo al sistema opera 
vo) en estado de backup. 


i 
i 
i ! -+ HUA = Tipo de biblioteca. 
j Lp xxx = Identificación del programa producto. 
! 1 Ls BK" — Constante (biblioteca en backup). 

i L_, 'PPS' = Constante (biblioteca de programa producto). 

Lp gggeggeg = Nombre de grupo de acceso. 


TS 


ipo de biblioteca para este caso podrá ser únicamente de los siguientes | 
tipos: 


— Fuente 
— Macros 
- Clists 


xx 
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- ICLdiSp — Proced — Carga 
— Params - Objeto = Gráficas 
— Menús - Docam — JCLstruo 


En formato libre codificar la clave del programa producto de que se trate. 


aesegese = Para efectos de poder codificar el nombre de grupo de acceso. 


Descripción de tipos de bibliotecas en cuanto a su contenido, 


Tipo de biblioteca 


Contenido 


Fuente 


Este tipo de bibliotecas estarán destinadas a contener 
sólo programas fuente correspondientes a un mismo 
sistema o subsistema. 


Macros 


Este tipo de bibliotecas estarán destinadas a contener 
sólo macro instrucciones requeridas dentro de los 
programas de un mismo sistema o subsistema. 


JCLdisp 


Params 


Este tipo de bibliotecas estarán destinadas a contener 
sólo disparadores de JCL que invoquen a su vez gru- 
pos de cláusulas de JCL en modo de procedimientos 
catalogados. 


Este tipo de bibliotecas estarán destinadas a contener 
sólo parámetros de control requeridos por los procesos. 


Proced 


Este tipo de bibliotecas estarán destinadas a contener 
sólo grupos de cláusulas de JCL formando procedi- 
mientos catalogados. 


Objet 


Este tipo de bibliotecas estarán destinadas a contener 
sólo programas en forma de módulos objeto corres- 
pondiente a un mismo sistema o subsistema. 


Carga 


Este tipo de bibliotecas estarán destinadas a contener 
sólo programas en forma de módulo de carga corres- 
pondientes a un mismo sistema o subsistema. 


Gráficas 


Este tipo de bibliotecas estarán destinadas a contener 
sólo gráficas correspondientes a un mismo sistema o 
subsistema. 


Clists 


Este tipo de bibliotecas estarán destinadas a contener 
sólo grupos de comandos de TSO (CLISTS). 


Menús 


Este tipo de bibliotecas estarán destinadas a contener 
sólo formatos de pantallas (MENÚS) para sistemas 
teractivos vía TSO. 


(Continuación) 


Estand Este tipo de bibliotecas estarán destinadas a contener 
sólo definiciones de estándares de uso generalizado. 
Docum Este tipo de bibliotecas estarán destinadas a contener 


sólo la documentación de las experiencias de la insta- 
lación de programas producto. 
JCEstrue Este tipo de bibliotecas estarán destinadas a contener 


sólo estructuras de JCL a ser utilizadas por medio de 
Menús de TSO. 


Para bibliotecas primarias del sistema operativo. 


Ter. Calif. | 2d0. Calif. 


1 -p Xuxa = Identificación individual asignada por el pr 
del sistema operativo, 

-~ 'SYS1' ~ Constante (biblioteca primaria). 

En donde: 
xxxxxaxx = Este nombre está ya predefinido por el proveedor del software del sistema 
operativo, identifica en sí la función de dicha biblioteca de acuerdo con la 
estructura funcional del propio software. 
Éste es el prefijo estándar delas bibliotecas que contienen al sistema operativo. 


bibliotecas secundarias del sistema operativo. 


DON 
Pi 


| Ter, Calit. | 200, Calit. 


E 


--— Xxx = Identificación individual asignada por el 
del sistema operativo. 
-—-—» 'SYS2' = Constante (biblioteca secundaria). 


En donde: 


Axar = Este nombre está ya predefinido por el proveedor del software del sistema 
operativo, identifica en sí la función de dicha biblioteca de acuerdo con la 
estructura funcional del propio software. 

'SYS2' = Éste es el prefijo que se deberá asignar a toda biblioteca que por cuestiones de 
seguridad contenga módulos modificados del propio sistema operativo. 
Nota: como estándar general. todo nombre de archivo o biblioteca deberá ser catalogado al momento desu 


creación. El catálogo mantendrá todos estos nombres 4 su volumen correspondiente: por lo tanto, dicho volumen 
indicará si el acchwo se encuentra en un paquete de decos o un volumen de cinta magnètica. 
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Es frecuente que una instalación pierda el control en cuanto a canti- 
dad, contenido, tipo e importancia de los archivos de datos que mantiene 
en resguardo. Esto resulta inconcebible si consideramos que es la función 
principal para la operación de los sistemas. El primer factor que se debe 
establecer para abordar este problema es clasificar el tipo de datos y archi- 
vos por orden de importancia. Como siguiente paso, es necesario estable- 
cer una identificación precisa para determinar los esquemas de respaldo a 
cada uno de ellos. Se deben considerar dos tipos de resguardo: el primero 
será para resguardo local, en donde se ubican aquellos archivos que por su 
naturaleza deben estar disponibles en el momento oportuno para la pro- 
ducción diaria; el segundo será para resguardo fuera de sitio y para archi- 
vos históricos o de difícil recuperación, de preferencia estarán ubicados 
en una bóveda contra incendio. El manejo preciso de fechas de caducidad 
dará la pauta para mantener archivos útiles. La identificación individual 
de cada archivo, por sí sola deberá contestar: ¿qué archivo es?; ¿a quién 
corresponde); ¿qué tipo de archivo es?; y ¿en dónde se encuentra dicho 
archivo? 
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Análisis, diseño y 
mantenimiento de 
sistemas 


Problema 


La prueba de que muchas Instalaciones 
desarrollan sistemas al vapor se da por el 
hecho de que frecuentemente “arreglan” 
programas a fin de emitir nuevos resultados, 
no por cambios obligados, sino porque no 
fueron previstos durante el análisis Inicial 


Este fenómeno se ha generalizado, pues son muy pocas las instalacio- 
nes en nuestro país que hacen cambios a los sistemas ya en producción, 
obligados por una verdadera necesidad. Son más las que permanecen en 
un eterno mantenimiento por falta de sistemas consistentes que no fue- 
ron diseñados meticulosamente apegados a estándares sólidos. Es muy 
común escuchar que el usuario necesita resultados nuevos, o cambios a 
los ya existentes, porque sus requerimientos de información están incom- 
pletos o simplemente porque no cubren sus necesidades concretas. Es 
más, muchos de los resultados que emanan de tales sistemas, ni siquiera le 
son de utilidad; y a veces hasta los recibe duplicados sólo que en distintas 
fases del sistema. 

Desarrollar un análisis y elaborar el diseño no es tarea sencilla, 
requiere mucho tiempo de estudio y dedicación. Representa una gran 
dosis de investigación y otro tanto de planeación. Implica bastante creati- 
vidad por ambos lados, el usuario y el analista. Obliga a una labor muy 
fuerte de análisis de necesidades de información, y por lo tanto, a un alto 
grado de conocimiento del medio para el cual se hará el diseño; es decir, si 
se va a diseñar un sistema para una aseguradora, requiere conocer bastan- 
te del área de seguros; por otro lado, si lo que se va a desarrollar es un siste- 
ma de control de impuestos, es vital dominar los conceptos fiscales; y así, 
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según el medio de que se trate. Esto no se puede adquirir de un día para 
otro. Asimismo, se debe tener un dominio absoluto de las técnicas de 
computación para lograr la traducción de las necesidades del usuario, en 
términos técnicos de procesamiento de datos; esto es muy diferente pues 
requiere de otro tipo de especialización. 

Es obvio que esto no se puede hacer empíricamente, o mejor dicho, 
nose debe, ya que en verdad son muchas las instalaciones que se atreven a 
improvisar sistemas, y los resultados, tanto en tiempo como en costo, son 
altísimos. Basta saber que muchos sistemas (si es que se les puede llamar 
así), desde su nacimiento y hasta la fecha, son de un alto costo y de muy 
poca utilidad para los usuarios, pues su aprovechamiento es casi nulo, y se 
Han casos en que para obtener un raquítico resultado se pasan semanas de 
proceso, arrojando infinidad de resultados que a nadie sirven, o a los cua- 
les el usuario todavía tiene que adecuar con información surgida de sus 
propios procedimientos manuales o por sistemas colaterales elaborados 
especificamente para tal fin. 

En auditorías efectuadas en diversas instalaciones, se han encontrado 
casos en que hasta un 90% de los resultados de un sistema, que consume 
semanas de proceso, son desperdiciados por no interesar a nadie. En oca- 
siones para obtener un resultado útil se tienen que hacer 5 o más cruces 
de archivos voluminosos de difícil creación. No es un secreto que en 
incontables ocasiones se hacen programas satélite bastante laboriosos, 
para generar algún resultado que no se tiene del sistema original. Esto y 
un sinnúmero de problemas bien conocidos por todos son los que produ- 
cen lo que a menudo se llama “masacotes” de programas, disfrazados de 
sistemas. 

La palabra análisis conlleva a un proceso de investigación minucio- 
so, imposible de desarrollar rápidamente o con pláticas improvisadas 
con el usuario. El concepto diseño representa un alto grado de inventiva 
y creatividad. Los pasos del análisis y diseño obligan a un proceso per- 
fectamente definido. Significan secuencia, estructura, orden, previsión 
y cualquier ingrediente lógico que ofrezca seguridad y confianza de que 
se cubren las necesidades completas de información para lo que el siste- 
ma está concebido. 


SUGERENCIAS DE SOLUCIÓN 


La solución más viable para atacar este problema no puede ser simple, 
más bien, debe ser completa, surgida de una gran cantidad de experien- 
cias y la recopilación de muchas prácticas probadas en el terreno de los 
hechos; obtenidas después de muchos fracasos y de la persistencia para 
lograr los correctivos de más beneficio. Por ello, la siguiente metodología 
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ha prevalecido con un amplio reconocimiento por quienes la han puesto a 
prueba. Cierto es que no es la panacea, pues quizá usted encuentre pun- 
tos que no se ajusten a sus propios procedimientos, pero si es así, mejórela 
y obtenga mayores resultados. Lo que sí es patente es que se partirá de un 
nivel por encima de la línea de la improvisación y el desorden. 


1. ELABORACIÓN DEL ANÁLISIS 
Y DESARROLLO DEL DISEÑO „o 


1.1. Surge la solicitud 
El disparador normal que origina el desarrollo de un sistema surge 


como una solicitud que hace el usuario al centro de procesamiento de 
datos. En dicha solicitud se destaca lo siguiente: 


+ Los objetivos, El usuario debe definirlos. La comprensión de estos 
objetivos es vital para el diseño integral. 

+ Las políticas. Los usuarios del sistema deberán establecerlas, ya que 
éstas normarán los criterios más importantes dentro de la filosofía 
del sistema. 


Es probable que el personal de sistemas ayude al usuario a fijar los 
objetivos y políticas. Tanto los objetivos como las políticas del diseño 
deberán quedar establecidos por escrito, procurando que sean claros y 
concretos, y sobre todo reales, apegados a los verdaderos requerimientos 
detectados. 


1.2. Investigación del sistema actual o 
necesidad (análisis) 


Es importante investigar si existe un sistema actual mediante el cual 
se obtengan los resultados o parte de éstos, para así determinar más ade- 
lante si es conveniente diseñar uno nuevo, considerando el perfecciona- 
miento de las operaciones y la reducción de los costos, así como nuevos 
resultados no estimados en el actual. Nótese que el sistema actual podría 
ser incluso del tipo manual 


1.2.1. Plan de investigación 


Para todo tipo de investigación se debe elaborar un plan o programa 
de trabajo. Esto debe ser previo al inicio de ella; el plan de investigación 
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deberá contener las actividades por realizar y el tiempo estimado de dura- 
ción de cada una de ellas. Esto dará una visión general de las actividades 
por realizar, el tiempo que se requiere, y los usuarios que se van a investi- 
gar o que van a intervenir en la investigación. Antes de elaborar el plan o 
programa de trabajo es necesario documentarse y ubicarse en el medio 
para el cual se hará el sistema. 

Ubicación en el medio. Antes de iniciar la investigación es funda- 
¡mental ubicarse en el medio a investigar con documentación existente y 
pláticas con personas que tengan amplio conocimiento del mismo; los 
elementos básicos son los siguientes: 


+ Estructura y organización de las áreas usuarias. Mostrará un panorama 
general de cómo iniciar la investigación y a quién dirigirse. 

+ Relación de la dependencia usuaria con otras dependencias, Dará 
un panorama más amplio de la función e importancia de esa depen- 
den 

+ Objetivos, políticas y funciones. Se obtendrá un conocimiento 
general de la dependencia en cuanto a funciones y resultados bási- 
cos que se logren, así como las normas que regulan los procesos 
administrativos vigentes. 

e Si se trata del rediseño de un sistema mecanizado, la ubicación se 
efectuará con la documentación correspondiente. De no existir ésta 
totalmente integrada, se efectuarán pláticas con el analista que dise- 
ñó o que mantiene el sistema actual, ya que es él quien está más 
enterado de ello e incluso conoce la operación actual y deficiencias 
más notables que originaron la solicitud al área de sistemas. 


Relación de actividades y estrategia de investigación. Para todo 
tipo de investigación se debe elaborar un programa o plan de trabajo, 
previo al inicio de ella. Este programa de investigación deberá contener 
las actividades por realizar y el tiempo estimado de duración de cada una 
de ellas, para obtener una panorámica completa de actividades, su 
secuencia, las áreas a investigar, asi como el tiempo total que tomará la 
investigación. 

Este plan puede variar, dependiendo del desarrollo de la investiga- 
ción, ya que puede haber aspectos que, por su importancia, justifiquen tal 
variación. Sin embargo, el plan inicial será la guía principal. Fundamen- 
talmente se debe considerar lo siguiente en el programa de investigaci 


+ Actividades. 

+ Secuencia. 

+ Duración de las actividades. 

« Áreas y personas involucradas. 
+ Observaciones. 
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1.2.2. Desarrollo de la investigación 


Una vez que se tiene conocimiento completo del medio por inves- 
tigar (ubicación), se procede a realizar la investigación; primordial- 
mente se tienen que hacer entrevistas, tanto a nivel ejecutivo como a 
nivel operativo. 

Para realizar una entrevista a cualquier nivel, es indispensable docu- 
'mentarse sobre las funciones y características del personal por entrevis- 
tar, así como preparar cuestionarios para obtener la información deseada; 
es posible utilizar las siguientes técnicas, dependiendo del caso. 


e Abierta. Cuando no existe un cuestionario predefinido. 

+ Cerrada. Existe un cuestionario específico de la entrevista. 

+ Mixta. Cuando existe un cuestionario, pero también incluye consi- 
deraciones abiertas. 


Entrevistas a nivel directivo. Por lo general, los primeros contactos 
en la investigación son las personas de mayor nivel jerárquico de la depen- 
dencia afectada; por tanto, al efectuar la entrevista deberá dirigirse básica- 
mente a obtener la siguiente informas 


» Objetivos especificos (sistema actual). Se deberá obtener informa- 
ción al respecto para afirmar o variar lo estudiado cuando se hizo la 
ubicación. Sobre el sistema a diseñar, es recomendable obtener: 


—Resultados principales. 
-Operaciones básicas. 

-Entradas al sistema. 

—Usuarios de los resultados. 

—Tiempos de respuesta de cada operación básica. 
Recursos utilizados, 

—Deficiencias detectadas y situaciones deseables. 


Relaciones externas de la dependencia. Se deberá obtener informa- 
ción acerca de las relaciones externas, para determinar si los objeti- 
vos del sistema a diseñar son reales o ubicados al medio. La informá- 
n por obtener será: 


-Servicios aparentes y reales de la dependencia. 
-Relaciones directas con otras dependencias. 

-Relaciones indirectas con otras dependencias. 

—Tiempo de respuesta de resultados para otras dependencias. 
-Canales de comunicación y de flujo de informa 
—Principales incongruencias entre dependencias. 
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+ Objetivos propios de la dependencia. Deberá considerarse que algu- 
nas veces los objetivos no son entendidos correctamente, por lo que 
se deben captar los verdaderos objetivos en el resumen de la entre- 
Vista, y despues verificar dichos objetivos durante el desarrollo de la 
investigación. De lo anterior deberán quedar precisados: 


—Políticas de la dependencia. Se debe considerar cuáles políticas 
están reglamentadas y cuáles no lo están; igualmente, los objetivos 
deberán verificarse en el desarrollo de la investigación. 

-Estructura de la dependencia. Es importante conocerla para tener 
un conocimiento más veraz acerca de ella y del personal a quién 
dirigirse; es conveniente que se derive de este estudio la presenta- 
ción del investigador con personal de jerarquía más baja para 
lograr su apoyo también, lo cual será útil y eliminará malos enten- 
didos sobre el porqué se realiza la investigación. 


Las consideraciones que se deben tomar en cuenta en una entrevista a 
el dirección, son las siguientes: 


+ Documentarse sobre las características y funciones del entrevistado; 
esto es útil para crear un ambiente de confianza. 

+ Utilizar la terminología adecuada al entrevistado, para un mejor 
entendimiento (evitar tecnicismos). 

+ Destacar la importancia de la participación del entrevistado en el 
desarrollo del proyecto por implantar, para lograr su apoyo. 

+ Dirigir la entrevista para que el entrevistado plantee las soluciones 
al sistema; para que lo sienta como creación suya, 

+ Hablar con tacto, sin herir susceptibilidades ni criticar. 

+ Saber escuchar, pero sin dejar de tener iniciativa. 

+ Contagiar entusiasmo por el proyecto. 

+ No considerar que una entrevista a nivel dirección es para recopilar 
información detallada. 

+ Sies necesario, dejar abierta la posibilidad de una siguiente entrevis- 
ta con una razón específica. Al término de cada entrevista es necesa- 
rio documentarla en el menor tiempo posible transcurrido desde el 
término de ella, considerando los siguientes puntos: 


—Número secuencial de entrevista dentro de la investigación. 
—Puesto del entrevistado. 

—Funciones del entrevistado 

-Objetivo de la entrevista. 

'uestionario de la entrevista. 

—Observaciones. 

-Conclusión de la entrevista, y resultados tangibles durante el aná- 
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—Persona y puesto siguiente a entrevistar. 


Si no se efectúa esta documentación al término de la entrevista, se 
pierden muchos aspectos correspondientes al objetivo de la investigación. 
Por lo tanto, se debe documentar cada una de ellas dentro del desarrollo 
de la investigación. 

Entrevistas a nivel operativo. Normalmente, este tipo de entrevis- 
tas se relaciona con el recorrido de la información. Esta forma de recopila- 
ción de información tiene por objetivo vislumbrar la operación real del 
sistema actual; y a fin de mecanizarlo, se deben considerar los siguientes 
elementos: 

Flujo de documentos y procedimientos. Ya que los procedimientos 
actuales seguramente son del tipo manual, se deberá recopilar informa- 
ción documental existente, en la cual se basen dichos procedimientos. 
Durante la recopilación de información se deben verificar los objetivos y 
políticas marcadas en las entrevistas a nivel dirección, porque en algunos 
casos están desvirtuadas en los niveles operativos, y un malentendido por 
el analista podría traer graves repercusiones posteriores. 

Entradas al sistema. Usualmente las entradas de un sistema son señala- 
das como generales, por lo que, si no se investigan a fondo dichas entradas, se 
puede omitir alguna que repercuta en el sistema y no esté declarada como tal, 
Se deben considerar los siguientes tipos de entradas: 


+ Definidas o lógicas. Son aquellas que por naturaleza del sistema y su 
operación son necesarias para lograr el objetivo de determinado sis- 
tema u operación. 

+ Impuestas. Son todas aquellas que por determinada política o nor- 
maentran en el sistema; este tipo es generalmente de carácter legal. 

+ Por excepción. Son las entradas que no están comprendidas en el 
objetivo básico del sistema u operación, pero que están dentro de los 
límites de los mismos, y que por ser de este tipo, son excepcionales, Se 
deberán considerar todas las entradas por excepción u operación del 
sistema, para determinar el volumen de entradas por excepción en 
relación con las entradas lógicas e impuestas. 

+ No definidas. Son de dificil detección en una entrevista. Lo más factible 
es detectarlas en el recorrido de la información, pero en algunas ocasio- 
nes en esta fase de la investigación serán detectadas al permitir que el 
entrevistado se explaye con un tipo de entrevista mixta. Es de suma 
importancia detectarlas, ya que pueden desvirtuar la política real del sis- 
tema. 


Resultados del sistema actual. Considerando los objetivos detectados 
en las entrevistas a nivel dirección, se debe recopilar información sobre 
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los resultados que cubran dichos objetivos, o en caso contrario, detectar 
cuáles son los resultados reales. Éstos resultados se clasifican de la 
siguiente manera: 


+ Lógico. Son los resultados que por naturaleza del sistema y su opera- 

ón deben estar comprendidos en él; se debe considerar la utilización 
de cada uno de ellos para evaluar si verdaderamente son aprovechados, 
según el enfoque que se predeterminó. 

+ Impuestos. Además de los resultados lógicos, existe este tipo de 
resultados, los cuales también deberán estar comprendidos en el sis- 
tema y su operación; pero se debe buscar la causa por la que están 
impuestos para tener una visión más clara de los alcances y repercu- 

ión de los resultados del sistema y su operación, si éstos fueran 
variados. 

+ Adicionales. Este tipo de resultados son los que se obtienen por ini- 
ciativa del personal que interviene en el sistema y su operación; se 
debe conocer la utilización de dichos resultados para detectar su 
funcionalidad, validez y legalidad. 

+ No comprendidos. Este tipo de resultados se determinarán al entre- 
vistar a este nivel; también se pueden lograr como aportación de las 
juntas operacionales; con esto se obtendrán más recursos de infor- 
mación al diseñar el sistema, y por tanto, mayor alcance operativo. 


Funciones operativas y toma de decisiones. En el transcurso de la 
investigación, y en particular al entrevistar personal operativo, se encuen- 
tran diversos tipos de operaciones que se realizan con la información en 
proceso, las cuales son las siguientes: manuales, mécanicas y electromecá 
nicas. Por el momento sólo se definen las manuales, ya que son la base del 
análisis. Existen diferentes operaciones manuales realizadas con la infor- 
mación, las más comunes son 


+ Recepción de información fuente. Es una operación de carácter 
manual; para ello existen controles como: folios, catálogos y factu- 
ras. Es importante que se conozca el origen de la información recibi 
da y sus datos de cuantificación. 

+ Selección y distribución de la información. Esta operación se realiza 
de acuerdo con sus características y objetivos de proceso. Es conve- 
niente detectar en esta fase el número de copias utilizadas en el 
documento fuente, la distribución de cada una de ellas y las opera- 
ciones realizadas, para detectar funciones duplicadas u operacione 
innecesarias. 

+ Proceso del documento fuente. En esta fase se deben investigar 
todas las operaciones que se realizan con el documento fuente, 
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así como los resultados que se obtienen; las operaciones más 
comunes son: 


-Cálculo con la información. Depende del objetivo de la operación 
y la necesidad de cuantificación de datos. 

-Adecuación de la información para una operación posterior, como 
son: codificación, señalamiento de conceptos, complementación 
de información, corrección y modificación de información, así 
como depuración de alguna otra información. 

-Cifras de control. Deben estar ligadas con los puntos de control 
del sistema u operación; asimismo, deberá considerarse su validez 
y utilización efectiva. 

—Destino del documento fuente. Es importante para obtener antigúe- 
dades de información y volúmenes, así como el medio donde se archi- 
ven los documentos y la periodicidad de consulta y caducidad. 


Es importante determinar la frecuencia de toma de decisiones en los 
niveles operativos, ya que puede ser la razón de las variaciones del sistema 
actual. También es importante determinar los tipos de decisiones y quié- 
nes están facultados para tomarlas, así como los límites de las mismas, 
para determinar si no está centralizada la toma de decisiones; ya que de 
ser así, repercutirá en el Funcionamiento normal del sistema. En general, 
existen los siguientes tipos de decisiones a nivel operativo: 


+ De supervisión o coordinación. Es el tipo de personal que conoce el 
sistema con mayor detalle, la gente más apropiada en la toma de 
decisiones a este nivel. Es muy importante determinar la autoridad 
de estas personas dentro del sistema, para ubicar los límites de deci 
siones correspondientes. Además, es importante determinar el 
tiempo de respuesta de la toma de decisiones al tener una variación 
el sistema para considerarlo dentro de la mecanización del nuevo 
sistema. 

+ De operación, Este tipo de decisiones debe ser muy limitado y vigi- 
lado; y en la investigación debe observarse la preparación del perso- 
nal para la toma de decisiones. El ámbito de la toma de decisiones en 
este nivel está acorde con el conocimiento del sistema, y es función 
del jefe inmediato fijar los límites. 


Hay consideraciones que se deben tomar en cuenta para cuando se 
entreviste a personal de nivel operativo. Es conveniente que antes de 
empezar una entrevista de este tipo exista una presentación general del 
analista de sistemas al personal a entrevistar, y después a cada uno de ellos 
según la secuencia de las entrevistas. Esto es lo primero que debe hacer el 
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jefe inmediato superior. El objetivo de esta presentación es que todos 
“conozcan al analista de sistemas y sepan el motivo de sus entrevistas, para 
evitar falsos rumores y situaciones difíciles en torno a éste. El analista 
debe considerar los siguientes puntos: 


+ Realizar con anterioridad un plan o cuestionario para cada 
entrevista. 

e Utilizar el lenguaje adecuado con el entrevistado para tener un 
mejor entendimiento (no mencionar tecnicismos). 

+ Dejar hablar libremente al entrevistado sobre su función, para cap- 
tar ideas que beneficien al sistema. 

+ No permitir que el entrevistado lo desvie del objetivo primordial de la 
entrevista. 

+ Seguir el orden planeado de entrevistas hasta donde sea posible, 

e Hablar con tacto y evitar ser el entrevistado, procurando ser discreto. 

+ Toda entrevista provoca situaciones comprometedoras, por lo cual 
es recomendable lo siguiente: 


—Seguridad en sí mismo. 
=Aplomo. 

-Present j. 
—Hablar claro. 

-No ser irónico. 

-No intimar con los entrevistados. 


Objetivos y políticas internas. Durante las entrevistas a nivel operati- 
vo es importante comprobar que el personal conozca los objetivos y políti- 
cas que han determinado los ejecutivos de la institución, y que aquéllos 
sean aplicados en cada uno de los pasos de la operación del sistema; si Ile- 
gan a detectar que están desvirtuados, habrá que considerarlo dentro del 
Funcionamiento del sistema actual, ya que esto podría estar afectando, y 
por tanto, se debe plantear a los niveles correspondientes. Aquí se deberá 
ser muy precavido, porque se podría considerar que el analista es un 
espía, y jamas volverá a contar con una participación veraz por parte del 
personal operativo. 

Recorrido de la información. Esta fase de la investigación es la 
observación y seguimiento del proceso de la información, desde su origen 
hasta la última actividad realizada para ello. Además, en esta Fase hay que 
poner especial cuidado, ya que podría existir alguna actividad duplicada o 
innecesaria, así como alguna falla de importancia que repercuta en el s 
tema a mecanizar. 

Durante el recorrido de la información se tienen que investigar los 
siguientes aspectos: 


140 CAP. 17. ANÁLISIS, DISEÑO Y... 


+ Orígenes del documento o información. Durante el recorrido de la 
información deberán determinarse los orígenes del documento 
fuente o información básica ael sistema, donde se consideren las 
dependencias y funciones que intervienen en la estructuración del 
documento fuente o información de origen. 

+ Normas y reglamentaciones. Aquí deberán estimarse las normas y 
reglamentaciones que rigen durante el recorrido de la información, 
y comprobar si se cumplen y son adecuadas. 

e Volúmenes. Se deberán considerar los volúmenes de información 
manejados en un periodo determinado, los cuales deberán tomarse en 
cuenta en el sistema investigado y en el posible sistema por diseñar. 

+ Periodicidad. Se deberá investigar la frecuencia del proceso y de 

ada una de las operaciones involucradas. 

e Variaciones. Aquí se investigarán las variaciones que sufre el siste- 
ma actual, así como las repercusiones ocasionadas por ellas, y las 
causas que las motivan. 

» Confiabilidad. En esta fase se tomará en cuenta la eficacia del servi- 
cio del sistema actual, para determinar la confiabilidad del mismo y 
la calidad de información que se maneja en ese momento. 

+ Antigúedad y caducidad de información. En esta fase se investigará 
la antigüedad de los archivos básicos del sistema, así como la fre- 
cuencia de su consulta. También se tomará en cuenta el respaldo de 
los archivos para la recuperación de información en caso necesario, 
y considerarlo en el sistema a mecanizar. 

+ Recopilación de formas preimpresas. Durante el recorrido de la 
información es conveniente tomar ejemplares de todas las formas 
preimpresas utilizadas en el sistema actual, y observar su correcta 
utilización. 

+ Complejidad del proceso. Deberá determinarse el grado de dificul- 
tad de operación del sistema en función de los recursos necesarios. 
Esto permite, entre otras cosas, determinar el tipo y nivel de perso- 
nal que realmente se requerirá. 

+ Tiempo de proceso. Se deberá obtener el tiempo de proceso de cada 
una de las operaciones del sistema, así como el tiempo global del 
mismo, en función de los volúmenes de información y la compleji- 
dad del proceso, a fin de determinar el tiempo estimado para la 
obtención de resultados en el nuevo sistema. 

e Distribución de resultados o documentos. Aquí deberán investigar- 
se las dependencias o personas usuarias de los resultados o docu- 
mentos obtenidos en el sistema, así como la utilización, 

e Tiempo de respuesta. En este punto de la investigación se debe obte- 
ner el tiempo de respuesta del sistema para cada uno de sus usua- 
rios, a fin de mejorarlo en el nuevo sistema. 
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+ Muestreos. En este muestreo deberá estimarse el volumen de datos 
que interviene, la complejidad del proceso y las variaciones que ten- 
ga, para tomarlo como un argumento de importancia a mejorar en el 
nuevo sistema a diseñar. 

« Recursos. Se deben tomar en cuenta los recursos tanto humanos 
como materiales con que cuenta el sistema actual, para proyectarlos 
a las necesidades del nuevo sistema. 

+ Costos. Este aspecto deberá ser lo más real posible, lo cual va en fun- 
ción de los recursos considerados tanto para el sistema actual como 
para el nuevo, y será la guía principal en el estudio de costo- 
beneficio del nuevo sistema a diseñar. 


1.3. Evaluación de la investigación 


1.3.1. Análisis de la información 
recopilada 


a etapa del análisis es primordial, pues es donde se va a evaluar el 
sistema que se investigó; por ello deberá integrarse toda la información 
recopilada durante la investigación. Una vez integrada, deberá estudiarse 
cada uno de los aspectos que componen la investigación, para determinar 
la operatividad de dicho sistema, y en función de esto, proponer mejoras 
al mismo y determinar la factibilidad de su mecanización, y en su caso la 
conveniencia. 

Por lo anterior, se puede observar que lo realizado en la investigación es 
fundamental para la evaluación, por lo que, si durante la investigación reali- 
zada no se consideró algún aspecto detectado en esta evaluación, deberá vol- 
ver a investigarse. 


1.3.2. Documentación de la investigación 


Para poder evaluar adecuadamente un sistema investigado, se deben 
considerar los siguientes puntos: 

Diagrama de flujo de la información analizada. Consiste en dia- 
gramar el flujo de la información del sistema actual, indicando todas las 
actividades del mismo, así como las áreas responsables de cada actividad. 
Para este tipo de diagrama es recomendable utilizar el denominado inter- 
departamental, en el cual se distinguen las distintas operaciones que 
sobre los documentos o información se van desarrollando de un departa- 
mento a otro. 

Descripción del diagrama. Debe contener el detalle de todas y cada 
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una de las actividades que se efectúan en el sistema, las cuales se investi- 
garon durante el recorrido de la información. También deberá cubrir las 
variaciones detectadas en dicho recorrido. La descripción de las activida- 
des debe tener el orden con el cual se efectúan en el sistema, para que ten- 
ga secuencia lógica. 

Estructura analizada. Este punto de la documentación deberá con- 
tener la estructura observada durante la investigación, y habrá que desta- 
car si existe una diferencia con la informada durante las entrevistas o 
documentación existentes. Los puntos que se deben considerar en esta 
estructura son: 


+ Organigrama de la dependencia: 


—Estructura jerárquica. 
—Funciones. 


Recursos existentes: 


Humanos. 
Materiales. 


Estos recursos deben estar relacionados con el organigrama de la 
dependencia. 

Objetivos determinados. Éstos deberán ser documentados y serán 
los señalados por los directivos de la institución. En muchas ocasiones, los 
objetivos no son logrados realmente; en ese caso, deberán señalarse por 
escrito las diferencias detectadas durante el trabajo de investigación. 

Es posible que los objetivos que persiguen los directivos no sean bien 
trasmitidos a otros niveles, que estén desvirtuados o bien afectando o 
complicando algunas operaciones. 

Normas y políticas determinadas. Al igual que en el punto ante- 
rior, éstas deberán quedar señaladas en la documentación según fueron 
interpretadas por los directivos. 

Las normas y políticas pueden ser aún más desconocidas o mal 
entendidas que los objetivos, por ello deberá documentarse toda dis- 
crepancia encontrada al respecto durante la investigación, para forta- 
lecer la evaluación. 

Anexos (documentos recopilados, catálogos, etc). Durante la 
investigación se deberá recopilar toda forma preimpresa o reporte utiliza- 
dos en el sistema, los cuales deberán documentarse en relación al diagra- 
ma de flujo de información. Si es posible, señalar en dichos ejemplares la 
información con que se llenan. 

Propuesta para mejorar el sistema. Durante la investigación y reco- 
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rrido de la información recopilada, el analista de sistemas debe percatarse 
de las fallas del sistema vigente, para proponer mejorar el sistema en los 
siguientes aspectos: 


+ Información fuente. 

+ Pasos innecesarios o duplicados. 

+ Funciones clave. 

+ Procedimientos críticos. 

e Utilización correcta de resultados. 

+ Objetivos, políticas y requerimientos actuales. 
e Recursos humanos y materiales necesari 

+ Costos. 


Propuesta de factibilidad de mecanización. Después de haber efec- 
tuado la investigación y recorrido de la información, el analista deberá 
evaluar el sistema y determinar si es conveniente la mecanización del mis- 
mo, efectuando un esbozo general de la(s) posible(s) solución(es) en caso 
de ser viable(s). 

Podría presentarse el caso de que el sistema empleado en ese momento 
pudiera ser mecanizado sin obtener muchas ventajas, pero ser más costoso; 
esta situación debe ser expuesta por el analista, dentro del documento. 


1.4. Diseño del sistema 


Durante el diseño del sistema, el trabajo del analista consiste en elabo- 
rar una o más opciones de automatización del sistema de procesamiento 
de datos que va a cumplir con los requerimientos de información de las 
áreas usuarias. 

En la formulación de opciones de un sistema propuesto se debe consi- 
derar muy importante la investigación real así como su evaluación, 
ya que depende de la comprensión y del conocimiento de los procedi 
mientos y problemas del sistema vigente para formular la(s) opción(es) 
del sistema propuesto para su aprobación. 

Cuando se diseña un sistema de procesamiento de datos se deben 
considerar ciertos objetivos referentes al perfeccionamiento de las opera- 
ciones y la reducción de los costos, así como la oportunidad y calidad de 
los resultados. Algunos de estos objetivos, son los siguientes: 


a) Estandarización de procesamientos de las unidades. 

b) Eliminación de funciones innecesarias. 

e) Eliminación de reportes, registros y formas innecesarias. 
d) Eliminación de datos superfluos. 
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e) Establecimiento de los controles necesarios y eliminación de los 
excesivos. 

f) Eliminación de duplicación de funciones. 

g) Eliminación de duplicación de objetivos. 

1) Eliminación de duplicación de operaciones. 

i) Eliminación de duplicación de informes y formas. 

j) Facilitar el flujo de trabajo y eliminar las altas y bajas del mismo. 

k) Oportunidad de los resultados. 

D) Calidad de los resultados. 
m) Utilización efectiva de los resultados. 


Un aspecto muy importante para el diseño de un sistema es aprove- 
char al máximo los recursos con que cuenta el computador a utilizar. Por 
lo tanto, es necesario que el analista conozca las facilidades de cómputo 
que tiene a su disposición. 

Para el diseño de un sistema es de vital importancia desarrollar los 
siguientes puntos: 


1. Estructura del sistema. 
+ Objetivos y políticas del sistema: 


-Ojetivo general. 
-Objetivos particulares. 
-Políticas del sistema. 


+ Resultados por obtener. 
Operaciones por realizar; manuales, semimanuales y electrónicas. 
+ Fuentes del sistema. 
+ Usuarios. 
e Recursos. 
+ Proveedores de los recursos. 
+ Componentes del sistema: operacionales, apoyo y regulación. 


N 


Diagramación. 


+ Diagrama general del sistema. 

+ Diagrama de captación de información. 
+ Diagrama operativo del usuario. 

+ Diagrama de procedimiento electrónico. 
+ Tablas de información y de decisiones. 


3. Evaluación del diseño. 
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» Sensibilidad. 

+ Restricciones. 

+ Adaptabilidad. 

+ Colapso. 

+ Puntos de control. 

+ Disponibilidad de recursos. 

e Posibilidades de implantación. 


4. Presentación del sistema. 


1.4.1. Estructura del sistema 


El inicio del diseño de un sistema es el desarrollo de la estructura del 
mismo; se debe considerar como estructura de un sistema el agrupamien- 
to y orden de todos los elementos componentes de éste, los cuales son los 
siguientes: 

Objetivos y políticas del sistema. Con base en la investigación reali- 
zada, y en la evaluación de la misma, donde se determinó el objetivo gene- 
ral y los objetivos particulares de cada fase, se deberán agrupar en orden 
de importancia todos y cada uno de ellos, así como las políticas y normas 
determinadas. Estos objetivos y políticas serán la base para el diseño del 
sistema: 


+ Objetivo general. Por ser lo primordial, marcará la pauta de todo el 
sistema. 

+ Objetivos particulares. Son aquellos que cubren un fin específico 
dentro de todo el sistema, y el conjunto de ellos debe lograr el objeti- 
vo general. 

+ Políticas. Son aquellas que reglamentarán el sistema; asimismo, 
marcarán sus límites, alcances e interrelaciones. 


Resultados a obtener. Van en función de los objetivos del sistema, 
los cuales ya fueron determinados por las autoridades usuarias del siste- 
ma; además, deben estar documentados. 

En esta etapa, el analista puede sugerir otros resultados que no sean 
los solicitados. Estos resultados serán creatividad del propio analista, ya 
que con el conocimiento que tiene del sistema, debe considerarlos, siem- 
pre y cuando detecte que son de utilidad para los usuarios. Por lo tanto, al 
diseñar el sistema deberá hacerse en relación con los resultados fijados 
durante el análisis. 

Operaciones por realizar. En el diseño del sistema es importante 
considerar todas las operaciones que se tengan que realizar, ya que son 
parte importante en el mismo. Las operaciones que intervienen en un sis- 
tema, básicamente son: 
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+ Manuales. 
+ Semimanuales. 
e Electrónicas. 


Estas operaciones deben estar bien definidas, indicando quién o qui 
nes las tienen que efectuar. 

Fueutes del sistema. Es indispensable saber dónde se originan las 
fuentes del sistema (éstas ya debieron ser detectadas en las investigacio- 
nes), para considerarlas en el nuevo diseño y determinar cómo y dónde se 
origina la información que, una vez procesada, emane los resultados 
deseados. 

Usuarios. El conocimiento del ambiente de los usuarios del sistema por 
diseñar es importante porque en un momento dado se deberá establecer con- 
tacto con ellos, pues serán los usuarios quienes utilicen los resultados, 

Recursos. Éstos deberán ser conocidos y tomados en cuenta para el 
diseño del sistema a mecanizar. Aquí se consideran recursos humanos, 
materiales y económicos. 

Proveedores de los recursos. Deberá conocerse cuáles son las 
dependencias que proporcionan los recursos, para responsabilizar a cada 
una de ellas a la hora de integrar los mismos. 

Componentes del sistema. Como ya se indicó anteriormente, 
éstos son los que integran la estructura de un sistema, los cuales pue- 
den ser los siguientes: 


+ Operaciones: procedimientos, entradas y salidas. 

+ Apoyo: servicios, recursos y técnicos. 

e Regulación: 1) internos: objetivos, políticas, criterios, puntos de 
control y decisiones; 2) externos: nuevos objetivos, nuevas políticas, 
nuevos criterios y decisiones. 


1.4.2. Diagramación 


La diagramación es una herramienta esencial para diseñar un siste- 
ma, ya que en ella se especifican gráficamente las actividades a realizar 
dentro de él, así como la secuencia de las mismas y quién las debe ejecu- 
tar. Por tanto, una vez estructurado el sistema, la diagramación es el plan- 
teamiento de cómo se va a desarrollar éste. Debido a los objetivos particu- 
lares que usualmente intervienen en los sistemas manejados en este 
medio, se ha generalizado el uso de los siguientes diagramas: 

Diagrama general del sistema. En este diagrama se indica el flujo de 
la información, donde se separan en cada columna los procesos a desarro- 
llar por cada dependencia que interviene en el sistema. En cada proceso 
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se describe de manera breve la actividad por desarrollar, indicando gráfi- 
camente qué información entra y cómo sale del proceso. 

Diagrama de captación de información. Aquí se indican los pasos 
para la captación de información a medios procesables, señalando las 
fuentes así como los destinatarios de la información transcrita y los pun- 
tos de control específicos de cada procedimiento. 

Diagrama operativo del usuario. Existen dos tipos de usuarios: el 
que únicamente utiliza los resultados del sistema y el que, además, ajusta 
la información. 

En general, este diagrama sólo indica las actividades que realiza el usuario 
para adecuar la información que entra al sistema y/o la distribución de los 
resultados obtenidos en el mismo. Es importante como consecuencia de este 
diagrama, que todas las actividades a desarrollar queden bien establecidas por 
los usuarios y que las respeten; de lo contrario, se corre el peligro de que el sis- 
tema no cumpla con los objetivos establecidos. 

Diagrama de imiento electrónico. Este tipo de diagrama es un 
grupo de símbolos preestablecidos que representan las operaciones del centro 
de computación. Estos símbolos se conectan por medio de flechas que indican 
la secuencia de las operaciones. El diagrama es el plan máestro de un sistema 
de computación; en él se muestran las entradas, las salidas y los procesos que se 
llevan a cabo para producir las diferentes salidas. Es una representación gráfica 
del flujo de los datos, a través de todo el proceso electrónico. Para diseñar el 
flujo electrónico, deben considerarse los siguientes aspectos: 

Configuración del equipo. Éste deberá tomarse en cuenta a fin de 
utilizarlo adecuadamente y optimizar cada uno de los pasos del sistema 
dentro del computador. Las características por considerar son las 
siguientes: 


+ Capacidad de memoria (relacionada con el nivel de multiprogra- 
mación). 

e Sistema operativo (relacionado con las facilidades técnicas). 

+ Periféricos (relacionado con la capacidad de almacenamiento de 
datos). 


Organización de archivos. En este aspecto, el analista debe hacer una 
investigación y evaluación para determinar la organización de archivos 
adecuada al sistema, dependiendo de las características del mismo; exis- 
ten las siguientes organizaciones de archivos: 


+ Secuencial 
e Indexada. 
e Directa. 
e Relativa. 
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> Particionada. 
+ Tablas de memoria. 
+» Banco de datos. 


Interrelación con otros sistemas. El analista debe tener conocimientos 
las funciones de otros sistemas, para: 


de 


+ Utilizar archivos ya creados. 
+ No duplicar resultados. 
+ Proporcionar información a otros sistemas. 


Compatibilidad con otros equipos. Esto está orientado básicamente al 
soporte en otros equipos para la operación continua del sistema cuando. 
ocurran descomposturas o siniestros en el equipo de cómputo propio. 

Programas de utilidad. El analista deberá conocer los programas de 
utilidad existentes en el centro de procesamiento, a fin de utilizarlos y evi- 
tar redundancia de programas, los más comunes son: 


e Sort, 

+ Merge. 

e Selector. 

+ Impresor. 

+ Rutinas especiales de uso común. 


Lenguajes. Es obligación del analista estandarizar los lenguajes de 
programación para el desarrollo del sistema, así como certificar la habili- 
dad del personal de programación para el manejo de los mismos. Entre los 
lenguajes más usados están: 


« Cobol. 

« Assembler. 

e Teleproceso (macros). 
«PL/L 

» RPG. 

e Fortran. 


Tablas. Es conveniente, si es posible, aprovechar el uso de tablas 
en el sistema; básicamente existen dos tipos de tablas: de decisión y de 
información. 

Tablas de decisión. Es un elemento gráfico en forma de matriz, que va 
a determinar la acción a realizar en función de un determinado problema, 
dependiendo de la condición presentada. 
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Tablas de información. Es también una matriz, pero a diferencia de las 
anteriores, aquí se consulta información en vez de tomar una acción. 


1.4.3. Evaluación del diseño 


Al terminar el diseño del sistema, y antes de presentarlo a considera- 
ción de los funcionarios que lo vayan a aprobar, el analista debe evaluar su 
propio diseño utilizando pruebas de escritorio; una vez realizadas éstas, 
presentarlo al grupo de analistas designado para el conocimiento y crítica 
constructiva del mismo, para que a su vez, con estas observaciones deter- 
mine los siguientes puntos de evaluación: 


+ Sensibilidad. Se caracteriza por detectar fácilmente las variaciones 
no comprendidas en el sistema. 

» Restricciones. Se refiere básicamente a las limitaciones del sistema, 
en cuanto a sus objetivos y políticas definidas para él. 

+ Adaptabilidad. Es la orientación que se le debe dar al sistema, para 
operarlo en distintas instalaciones del usuario (en caso de existir). 
Desde luego, esto depende de los objetivos propios de la institución 
y del sistema. 

+ Colapso. Se refiere a determinar el punto o parte del sistema en don- 
de no pueda soportar más variaciones de operación, apoyo o regula- 
ción; esto origina que se desvirtúe el sistema. 

+ Puntos de control. Básicamente deberán existir puntos de control 
en las interfases de la operación del sistema, con lo cual se deben 
determinar cuáles son esos puntos de control y cuáles son las correc- 
ciones a las variaciones detectadas por medio de ellos. 

+ Disponibilidad de recursos. Aquí se debe tomar en cuenta qué recursos 
son posibles de utilizar para el desarrollo del sistema, y qué disponibili- 
dad existe para contar con ellos en el momento adecuado. 

e Posibilidades de implantación. Esencialmente este punto está orien- 
tado a determinar las posibles opciones de implantación, las cuales 
dependen primordialmente de tres elementos: tiempo, recursos y 
costos. 


1.4.4. Presentación del sistema 


Una vez diseñado y evaluado e* sistema, se debe presentar a conside- 
ración de los funcionarios correspondientes, para su aprobación o ajuste. 
La forma de presentación del sistema depende de los recursos con que se 
cuente para ella, los más utilizados son los siguientes: 
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+ Transparencias y películas. 

e Flip chart (hojas grandes, un caballete). 

+ Material para proyectar Cuerpos opacos. 

+ Material para proyectar cuerpos transparentes. 

+ Material adherible para franelógrafos. 

+ Figuras imantadas para pizarrones o superficies. 

e Cartulinas o cartones ilustrados. 

+ Carpeta de presentación (hojas cambiables, de tamaño más pequeño 
a las utilizadas en el flip chart). 


De no contar con los recursos descritos, se puede auxiliar de un piza- 
rrón, utilizando de preferencia gises de colores. 

Es muy importante contar con una documentación que respalde esta 
presentación, la cual debe contener lo siguiente: 

Introducción. Se deberá explicar, en forma breve: 


+ Razones por las que se decidió efectuar el estudio de factibilidad de 
diseñar e implantar el nuevo sistema, y quién lo solicitó. 

+ Indicar el objetivo general del nuevo sistema. 

+ Descripción general de las opciones de implantación. 


Objetivos del sistema. Se deben describir en forma breve los objetivos, 
tanto generales como específicos, del sistema, los cuales debieron ser fija- 
dos por los altos funcionarios. 

Diagrama de flujo de la información del sistema. Deberá ser una 
representación gráfica con la que cualquier persona de cierto nivel com- i 
prenda el flujo de la información; es recomendable utilizar dibujos y/o l 
esquemas ilustrativos. 

Ventajas operativas, administrativas y de información. Se deben des- 
cribir brevemente las ventajas más importantes del sistema, tanto las ope- 
rativas como las administrativas. Estas ventajas deberán estar en relación 
con el sistema actual; o bien, si los dos sistemas se asemejan en algunas 
ventajas, indicar en forma concisa las diferencias, si es que las hay. 

Información a procesar. Indica las distintas fuentes de información y 
su contenido, lo cual muestra a los funcionarios el tipo de información 
con que se cuenta para la obtención de los resultados. 

Resultados a obtener. Se indica cada uno de los resultados más impor- 
tantes que se van a obtener con el sistema. Se debe especificar la utiliza- 
ción de cada uno; algunos serán autoexplicativos. 

Proyecciones a futuro. Se indicará en forma concisa lo que el sistema, 
después de implantado, puede absorber o crecer, lo cual depende de las 
necesidades que se presenten a futuro. 

Conclusiones. Se deberá indicar la importancia que representa para el 
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usuario el buen funcionamiento del sistema a implantar y las considera- 
ciones necesarias para el logro de ello, como apoyo, vigilancia, manejo 
adecuado, etcétera. 

Elementos necesarios para la implantación del sistema. Se deberán 
indicar en cada una de las opciones presentadas los recursos humanos y 
materiales necesarios para la implantación del sistema, tanto en procedi- 
mientos manuales como electrónicos. 

Diagrama general del sistema. Es la presentación gráfica de cada una 
de las fases del sistema, en forma general, donde se especifican y deslin- 
dan las responsabilidades y actividades de cada una de las dependencias 
que deberán intervenir en el sistema. 

Descripción del diagrama. Se describirán cada una de las fases a realizar, 
qué tipo de información entra, dónde se obtuvo y qué resultados produce 
esta fase. Se deberá empezar con la acción a realizar más importante, 

Tiempo probable de implantación. Se debe considerar el tiempo 
probable de implantación, representado por un calendario de trabajo, 
donde se señalen las actividades, la duración y las fechas de cada una, 
así como los responsables de su desarrollo. 

Anexos. Se deberán integrar en esta documentación las formas a uti 
zar para la captación de información, documentos fuente y ejemplos de 
cada uno de los resultados a obtener. 

Además de la documentación, se deben con 
aspectos, para el desarrollo de la presentación: 


iderar los siguientes 


a) 


Preparación: 


'ijar objetivos. Clarificar el alcance de la presentación. 

+ Organización. Deberá organizarse el material de apoyo para la 
presentación, así como la secuencia del mismo. 

+ Simplicidad. Se deberá simplificar lo más posible, 

+ Definición. Habrá que utilizar la terminología adecuada con los par- 
ticipantes y, en su caso, definir los términos técnicos a utilizar. 

+ Analogías. Entre más abstracto sea el contenido, más analogías se 
necesitan 

+ Conocimiento. El conocimiento total del sistema es indispensa- 
ble para su presentación, ya que ello dará confianza al analista y 
podrá responder a las preguntas que se le planteen. 


b) Presentación. Ésta depende de la habilidad del expositor. Se consi- 
deran los siguientes aspectos: 


+ Autoridad. Los participantes deberán tener en cuenta que el 
expositor cuenta con autoridad frente a ellos. respaldado por su 
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competencia, sinceridad e integridad y sobre todo por el conoci- 
miento del sistema. 

+ Contacto visual. Se debe ver a los participantes, esto dará una 
idea al expositor de cómo adaptarse a las necesidades de ellos. 

+ Voz. Ésta deberá ser adecuada, se debe poner énfasis y hacer las 
pausas que destaquen ciertos puntos de la presentación. 

+ Escritura. Se deberá escribir con letra grande y espaciada, así 
como suprimir lo innecesario. 

+ Movimientos. Éstos deberán estar bien calculados, procurando 
no distraer la atención de los participantes. Bien empleados, pue- 
den ayudar a subrayar lo que se está explicando. 

e Participación. Durante la presentación, procurar que los partici- 
pantes intervengan en la misma; para esto, hay que considerar los 
siguientes elementos: 


—Humorismo. Relaja a la gente y ayuda a producir una atmósfera 
agradable, donde los participantes se sienten libres para exterio- 
rizar ideas y formular preguntas. 

—Contestar, El expositor debe evitar contestar mucho o con brus- 
quedad. Debe dialogar con todos los participantes, cuidando de 
no convertir la presentación en una plática generalizada. 


Nota: Se destaca que el conocimiento total del sistema es indispensa- 
ble para su presentación, ello dará seguridad al analista, quien obtendrá la 
confianza del auditorio. 


2. IMPLANTACIÓN DEL SISTEMA 


En esta parte se hará referencia únicamente al sistema electrónico, ya 
que el sistema aprobado puede ser de otro tipo, en cuyo caso, la labor del 
analista termina en las opciones que expuso. 

Una vez aprobado el sistema propuesto, se deberá diseñar con detalle 
cada paso, tomando en consideración las observaciones que se hayan 
hechos al sistema durante sus presentaciones. 

Otros aspectos por considerar son: la preparación de los elementos 
humanos que intervendrán en cada una de las actividades que requiere el 
proyecto, los recursos con los que decidió implantar el sistema, así como 
las características del equipo por utilizar, para aprovecharlo mejor. La 
implantación es la fase donde se pone en práctica el concepto teórico de 
un sistema, es la más objetiva del desarrollo; es la culminación de activida- 
des como planeación, análisis, diseño y programación del nuevo sistema. 
Es la parte en la que el analista debe demostrar su habilidad y conocimien- 
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tos para lograr el máximo aprovechamiento y efectividad de todos los 
recursos humanos y materiales, mediante una coordinación precisa y cui- 
dadosa. 

Lo anterior requiere del conocimiento complejo del sistema, pero 
esto no quiere decir que él lo tenga que hacer todo, sino que mediante 
bases de planeación y estructuras organizacionales debe delegar en otras 
personas ciertas funciones de detalle. 

Entre las funciones de la implantación por realizar están las siguientes: 


2.1. Diagramación 


Como ya se dijo, habrá que considerar las observaciones que se hayan 
hecho al sistema durante las presentaciones, y esto deberá reflejarse en los 
diagramas a utilizar en tal sistema. 


2.1.1. Diagrama general 


Este diagrama especificará en forma muy general el recorrido de la 
información, indicando las áreas internas y dependencias externas que 
intervendrán en el sistema. 


2.1.2. Diagrama particular de procedimientos 
manuales 


Este diagrama es el desglose específico de las actividades a realizar por 
ada área usuaria, primordialmente en lo que se refiere a captación de infor- 
mación (codificación y realimentación de información) y uso de cada uno de 
los resultados por obtener en el sistema. Por otro lado, el diagrama también 
comprende las actividades de conversión de información fuente a medio 
procesable. 


2.1.3. Diagrama de procedimientos electrónicos 


Es la representación gráfica del flujo y proceso de la información, en 
un computador para obtener los resultados previstos en el sistema. El 
diseño de este procedimiento dependerá por un lado del tipo y configura- 
ción del equipo de la instalación y, por el otro, de la calidad del personal 
con que se cuenta en programación. Por último, se debe considerar la no 
saturación del equipo con un solo proceso. 
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El momento en que se debe iniciar la programación es determinante. Al 
llegara este punto, el diseñador ha invertido meses de tiempo y esfuerzo en la 
investigación y diseño; sin embargo, durante el diseño cualquier cambio, 
cualquier factor descuidado previamente, por lo general no causa retrasos o. 
riesgos; normalmente todo lo que se requiere para rectificar el caso, es adi 
nar una nota de algún registro, cambiar una anotación en el diagrama de pro- 
ceso, o dar de baja una línea del esquema. No obstante, en el momento de 
empezar la programación cambia el panorama. El analista es el responsable 
de cuidar que los programas desarrollados estén de acuerdo con las especifi- 
caciones de los procesos diseñados. 

Es importante saber que es fácil hacer cambios en el sistema antes de 
programarlo, pero una vez hecho esto, cualquier cambio se dificulta; esto 
significa que el sistema propuesto debe estar correcto y completo antes de 
pasar las definiciones a la fase de programación. Por lo tanto, la definición 
de los programas del sistema deberá hacerse una vez que se tenga en for- 
ma detallada el diagrama de procesamiento electrónico, y que el analista 
esté totalmente seguro de los objetivos del sistema, así como de lo que va a 
hacer cada uno de los programas que intervienen en el mismo. 

Para llevar a cabo las definiciones de cada uno de los programas, es 
conveniente que el analista se apegue a los siguientes puntos: 


2.2.1. Elementos para la definición de un programa 
Identificación. Estará formada por los siguientes datos: 


+ Nombre del sistema y subsistema. 
+ Nombre del analista. 

+ Clave del programa. 

+ Datos cronológicos. 


Objetivos. Contendrá una explicación concisa de los resultados 
que se obtendrán en dicho programa y la relación, si la hay, con otros 
programas. 

Entradas. Aquí se proporciona la información genérica con las 
características de los archivos de entrada, tales como: 


« Nombre externo del archivo. 

+ Posiciones por registro. 

+ Factor de bloque o registros por bloque. 
+ Dispositivo o dispositivos. 
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+ Posición por la que está clasificado (si está clasificado). 
+ Organización. 

+ Llaves de acceso. 

+ Método de acceso. 

+ Tipo de etiquetas- 

+ Nombre interno. 

+ Número de volumen de dispositivo. 


En caso de existir una clasificación previa, la cual se utilizará en el 
proceso, deberá especificarse la llave de clasificación y los niveles de la 
misma, referidos al nombre o nombres de los campos, así como las posi- 
ciones relativas dentro del registro de datos. Invariablemente se anexará 
un formato correspondiente a cada uno de los archivos de entrada, en 
donde se detallarán las posiciones que ocupa cada campo, así como el tipo 
de caracteres que contiene cada uno. 

Si el programa utiliza lectura de parámetros, deberá precisarse, En 
esta sección de entradas deberá anexarse por separado el formato de los 
párametros, así como las especificaciones, claras y precisas, donde se 
explique el uso de todos y cada uno de los parámetros. Cuando el progra- 
ma requiera armar una tabla, es necesario proporcionar el número de ele- 
mentos que la constituirán, así como el formato de los mismos, mencio- 
nando la necesidad de por qué se definió. 

Salidas. Su contenido es similar a lo expuesto en el párrafo de entradas, 
salvo para resultados por impresora, en cuyo caso deberá anotarse la clave de 
la “forma de papel” que se utilizará, número de tantos, si la impresión es a 
sextos u octavos, cinta de control, carro normal o especial, o en su defecto, 
parámetros de control de saltos de impresión. 

En lo que respecta a formatos de registro, lo especificado para archi- 
vos de salida. 

Proceso. Esta parte de la definición de un programa es la que normal- 
mente presenta una mayor dificultad para su realización y entendimien- 
to; esto se debe principalmente al hecho de pretender decir cómo se quie- 
re hacer, y por consiguiente, no se atiende lo que se desea que el programa 
haga. La descripción del proceso debe ser lo más simple posible, atendien- 
do con precisión los resultados que se desean. 

Procesos de conversión y depuración. En este tipo de procesos es fre- 
cuente que sólo se depuren los campos considerados como información 
básica, descuidando el resto de la información. Por consiguiente, se 
sugiere que este tipo de programas hagan una depuración más exhaustiva 
de todos y cada uno de los campos que integran un registro de informa- 
ción. Con esto se evita que en programas subsiguientes, ya sean de la pro- 
pia aplicación o bien de otra conexa, haya la necesidad de depurar infor- 
mación. De igual forma, es conveniente que no se rechace un registro a la 
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primera inconsistencia detectada, sino que la depuración debe continuar 
hasta agotar ese registro, marcando todas y cada una de las inconsistencias 
detectadas. Esto evita correcciones parciales, y por consiguiente la reali- 
mentación de la misma información, más de una vez. 

Especificación de campos por procesar. Cuando se haga referencia a 
los campos sujetos al proceso, deberán corresponder, tanto la descripción 
del campo como las posiciones que ocupa dentro del registro, a las especi- 
ficaciones en el formato de registro. 

Es frecuente el error de no correspondencia entre nombres y posicio- 
nes por fallas de transcripción mecanográfica, por esto es recomendable 
que el analista cuide esos detalles. 

Procesos de datos clasificados. Cuando la información se presenta 
clasificada, con el propósito de producir uno o más cortes, o bien acumu- 
laciones de información que corresponden a la misma llave de clasific: 
ción, es importante que se den los criterios para que, al verificar la 
secuencia, el programa tenga la opción de tratamiento en caso de incon- 
sistencia. Ésta puede ser fuera de secuencia, registros duplicados, o espe- 
cificar que el archivo no está clasificado. 

Debe insistirse en que para procesos de corte y/o acumulación por 
llave de clasificación siempre deberá verificarse la secuencia, y en conse- 
cuencia, también se especificará el orden de clasificación de la informa- 
ción; lo mismo procede para cruces de archivos clasificados que preten- 
den complementar información y/o actualización. 


Cruces de archivos para actualización y/o complementos de informa- 


ción. Aparte de lo expuesto en el párrafo relativo a información clasificada 
en este tipo de procesos, es de gran importancia dar los criterios para 
cuando la información no encuentra correspondencia en uno o más de 
los archivos objeto del proceso. Nunca se debe presuponer que toda la 
información encuentra correspondiente; o que un archivo se termina pri 
mero que otro, o bien que el programador tiene los antecedentes para dar 
un tratamiento adecuado a esta información, ya que sólo producirá resul- 
tados inadecuados. Por lo anterior, el analista deberá dar siempre, por 
escrito, los criterios para el tratamiento de estos casos. 

Rutinas de cálculo, Para toda rutina de cálculo el analista debe pro- 
veer, dentro de la definición, las fórmulas matemáticas mediante las cua- 
les se llega al resultado deseado. Lo anterior es más claro y preciso que 
pretender describir en forma literaria dichas fórmulas. 

Se debe prestar atención a los campos numéricos con los cuales se van 
a hacer las operaciones, sobre todo con aquellos que podrían ser negati- 
vos, esto último con frecuencia pasa inadvertido en las definiciones. 
Cuando los campos numéricos por procesar no se hayan depurado previa- 
mente, es indispensable hacerlo saber en la definición del programa, para 
lograr resultados oportunos y adecuados con dicho programa. 
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Condiciones de excepción. Todas las condiciones previsibles de 
excepción que sean del conocimiento del analista se deben poner en la 
definición. Ejemplo: si un programa procesa registros tipo 1, 2 y 3, deberá 
preverse qué hacer cuando un registro no sea ni l, ni 2, ni 3. 

Programas con dos o más opciones. En estos casos deberá poner aten- 
ción en no hacer confusa la definición, procurando dejar independiente 
cada opción y dando marcada preferencia a la manera en que el programa 
optará por alguna de sus opciones; en otras palabras, deberá espe 
el método de selección de la opción. Las opciones serán dadas por pará- 
metros de control. 

Se deberá adicionar todo comentario útil que sirva para aclarar concep- 
tos o dar una idea del tipo de información que se ha de procesar, servirá de 
gran ayuda, tanto para el programador como para los analistas que tengan 
que realizar trabajos futuros de mantenimiento con dichos programas. 

Cifras de control. Esta parte de la definición requiere mucha aten- 
ción por parte del analista; se debe cuidar especialmente que las cifras de 
control cubran su principal objetivo: controlar los resultados del progra- 
ma. Esta valiosa herramienta por lo general no se usa en forma adecuada, 
renda a veces muy problemático o imposible cuadrar dichas cifras de 
control. 

Otra gran dificultad que presentan en su mayoría las cifras de control 
es que no se proporcionan criterios que permitan establecer la relación 
entre las mismas; por tal motivo, en muchas ocasiones sólo la persona que 
definió el programa sabe en qué forma se verifican esos resultados, lo cual 
en un centro de procesamiento no es recomendable. Por lo anterior, se 
sugie 


+ Realizar un estudio detallado de las cifras de control del programa 
para que sean contabilizados todos los registros del proceso. 

+ Proporcionar el número de posiciones de que constará cada cifra de 
control, ya que es el analista quien conoce los volúmenes por procesar, 
evitando con ello el sobrepeso de los contadores correspondientes. 

+ Anteponer una letra o combinación de letra y número a la leyenda 
correspondiente a cada una de dichas cifras; así será más fácil esta- 
blecer por medio de una fórmula la relación entre ellas. Como ejem- 
plo se muestra la siguiente situación: 


A- Registros leídos 
B- Registros tipo 1 
C- Registros tipo 2 
D- Registros tipo 3 
E- Registros sin tipo XXX, XXX 
F- Registros erróneos XXX,XXX 
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El — Tipo 1 XXX,XXX 

F2 — Tipo 2 XXX,XXX 

F3 — Tipo 3 XXX,XXX 
G- Total grabados XXX, XXX 
H- Registros maestros gra- 

bados XXX,XXX 
1- Registros detalle graba- 

dos XXX,XXX 


Fórmulas de verificación: 


A=B+C+D+E+F 
F =F +F2+ F3 
G-H+1 

H=B-Fl 

1 =(C+D)- (F2 + F3) 


2.2.2. Sugerencias acerca de la 
elaboración de programas 


Para que el programador realice una prueba eficiente del programa es 
indispensable que el analista provea a aquél de criterios para elaborar 
datos prueba, de modo que cubran todas las condiciones que debe prever 
el programador, como casos de excepción, exclusión, fuera de secuencia, 
inconsistencia, etc.; ya que cuando se deja a criterio del programador, 
normalmente probará condiciones simples o la rutina principal del pro- 
grama, Debe entenderse que lo que se pide son criterios para elaborar la 
prueba, los cuales, para una mayor eficiencia, será necesario proporcio- 
narlos por escrito; con ello, el analista estará en condiciones para certifi- 
car el buen funcionamiento de dicho programa. 

Existen analistas cuyo conocimiento de la aplicación a su cargo les per- 
mite concluir la solución de un problema mediante la definición de un solo 
programa que cubre múltiples opciones y de uso simultáneo de varios dispo- 
sitivos periféricos, donde se logra obtener los resultados requeridos. Sin 
embargo, el problema surge cuando: 


e Se va a actualizar dicho programa. 
+ Quien lo realizó ya no trabaja en la institución 


Además, complica la operación de la computadora, cuando bloquea 
equipo periférico para otros procesos. Por tanto, si se toma en cuenta el 
sistema operativo y el equipo disponible, así como la futura depuración y 
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mantenimiento de los actuales sistemas, se sugiere que mejor se busque la 
posibilidad de producir dos o más programas, que serán más fáciles de 
Fenlizar, actualizar y mantener, y que también darán una mayor oportuni- 
dad de que los analistas que en el futuro atiendan dichas aplicaciones, 
adquieran en un menor tiempo el conocimiento de los programas corres- 
pondientes, tanto en su lógica como en el tipo de resultados que arrojan. 
Con el propósito de estandarizar la terminología, se debe entender por: 


+ Modificación. Todo cambio que en mayor o menor grado afecta la 
definición original de un programa cuando éste aún se encuentra 
en fase de elaboración o prueba. 

+ Actualización. Los cambios a un programa que ya ha estado en pro- 
ducción. 


Para estos casos, lo más importante es que la actualización o modifica- 
ción se presente siempre por escrito, con fecha y forme parte de la definición 
original por medio de hojas anexas, las cuales, para mayor claridad, deberán 
hacer mención a la página y/o párrafo que afectan de la mencionada defini- 
ción original, o bien, de modificaciones o actualizaciones previas. Lo impor- 
tante es que haya antecedente. 

Es importante que el analista exponga una plática sobre los objetivos 
del sistema a los programadores que intervinieron, pues tiene gran tras- 
cendencia para la persona conocer cuáles son las áreas de afectación con 
el trabajo por ellos realizado. Lo anterior obedece al principio establecido 
en las relaciones de trabajo, que dice: “Todo empleado debe conocer la 
importancia y alcances de su trabajo en forma integral”. Además de lo 
anterior cabe mencionar la importancia de los siguientes puntos. 

Relación entre programadores y analistas. Una vez estudiada la defini- 
ción por el programador, deberá establecerse una plática o serie de pláti- 
cas con el analista. Esto es para que el programador certifique que la defi- 
nición del programa ha sido entendida o para que se disipen las dudas que 
tenga. Si estas pláticas no se hacen oportunamente, retrasarán la entrega 
del programa. 

Revisión y aprobación de los programas en función del tiempo. Una 
vez que el área de programación entregue los programas al analista, es 
recomendable que éste efectúe la revisión de todos los productos lo más 
pronto posible, y que no espere a que se efectúen las pruebas de volumen 
correspondiente, para que el programa sea aprobado o rechazado, ya que 
la demora al revisar el programa trae como consecuencia que el progra- 
mador que lo hizo lo olvide, o que ya no trabaje en la institución. 

Trabajos urgentes. En este tipo de trabajos no deberán pasarse por alto 
las definiciones por escrito de los programas, ya que la experiencia nos 
dice que cuando no existen definiciones, ocurren malas interpretaciones 
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y como consecuencia, no se obtienen los resultados deseados. 

Acceso a los programas fuente. Este acceso sólo deberá efectuarlo el per- 
sonal del área de programación, y ocasionalmente el personal de análisis. 

Elaboración de programas. La elaboración de los programas la llevará 
a cabo el personal del área de programación, a medida que las definicio- 
nes les sean entregadas por el analista. Esos programas deberán reunir los 
requisitos establecidos; si no es así, deberán regresarlos de inmediato al 
analista, indicando las condiciones que no cumplen. 

Revisión y aprobación de los programas. Esta etapa es una de las más 
importantes y de ello debe hacer conciencia el analista de sistemas, ya que 
de una buena revisión de los resultados de los programas, depende en 
gran parte el éxito de un sistema, porque ello evita modificaciones o 
actualizaciones de los programas en la Fase de operación del sistema, por 
falla de programas o resultados erróneos. 

in de los programas, aunque es muy tediosa y aburrida, debe 
ser muy cuidadosa y tienen que verificarse todas las condiciones posibles, 
las cuales se deben plantear en los criterios de datos de prueba. El analista 
nunca deberá confiarse en que el programador haya probado tal o cual 
condición; deberá comprobarlo él mismo. Una buena revisión de los pro- 
gramas de un sistema se refleja en el manejo del mismo, es decir, durante 
dicha operación no existen modificaciones o actualizaciones de los pro- 
gramas; si existieran, serían por excepción y con plena justificación. 

Pruebas de programas con información real. Para hacer este tipo de 
pruebas es recomendable que además de las pruebas de los programas con 

ros prueba durante su elaboración, se hagan otras, pero con informa- 
ción real. Esto se hace para depurar la programación que va a intervenir 
en el sistema. En este tipo de pruebas es recomendable que los datos que 
se seleccionen contengan la mayor variabilidad de condiciones posible, a 
fin de probar a toda capacidad cada programa, y que los programas donde 
se detecte alguna anomalía sean modificados de inmediato; además, se 
debe actualizar la documentación correspondiente. Si se efectúan este 
tipo de pruebas en forma adecuada, los problemas que se presenten serán 
mínimos. 

Pruebas del sistema. Al terminar la programación, el analista tiene ya un 
grupo de programas definido por él. cada uno de los cuales se ajustan, unosa 
otros, para formar un sistema funcional. Es probable que debido a la carencia 
de comunicación, aun cuando se le definió al programador lo que se espera- 
ba que hicieran los programas, éstos no estén de acuerdo con las necesidades 
del sistema; asimismo, la programación individual de dicho programa los 
puede hacer inconsistentes unos con otros, y en consecuencia, éstos, como 
un todo, no trabajen como un sistema completo. 

Debe asegurarse que los programas probados por separado no conten- 
gan estas deficiencias, y por tanto, constituyan un sistema de proceso 
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aceptable. Esto se obtiene con la prueba del sistema, en donde la secuen- 
cia de los procesos debe engranar perfectamente. La preparación de datos 
es responsabilidad del analista; debe probar todas las opciones posibles 
para el sistema desde cualquier ángulo, para así detectar los errores que 
haya cometido él o los programadores. 

La prueba del sistema es un procedimiento cíclico, en el cual los 
errores detectados requieren de modificaciones a la programación, y 
una vez corregidos los programas problema, se procesa nuevamente 
el sistema para detectar cualquier error que no hubiera surgido antes. 
Si el sistema es muy grande (más de 20 programas), es conveniente 
que la prueba se realice por partes o subsistemas. Una vez eliminados 
los errores de cada uno de ellos, se podrá probar el sistema completo. 

Las entradas y salidas en cada uno de los programas deben ser revisa- 
das cuidadosamente, poniendo mayor atención al primero y último regis- 
tros de cada archivo, ya que es ahí donde existen más errores. La docu- 
mentación del sistema debe ser actualizada con todos los cambios que se 
hayan hecho durante estas pruebas. Las pruebas del sistema pueden ser 
piloto o en paralelo. 

Pruebas piloto. Este tipo de prueba es el que se hace cuando no existe 
ningún sistema anterior contra el cual se comparen los nuevos resultados. 

Pruebas en paralelo. Este tipo de pruebas se utiliza cuando anterior- 
mente existía algún sistema con el cual se comparaban los resultados de 
uno nuevo. Estas pruebas, como su nombre lo indica, consisten en correr 
simultáneamente el antiguo y el nuevo sistema. El objeto del trabajo en 
paralelo de los dos sistemas es comprobar si el nuevo funciona con los 
mismos resultados que el anterior. En este tipo de pruebas deben partici- 
par todos los elementos que normalmente intervendrán cuando funcione 
el sistema en forma real. 

Por lo general, para estas pruebas es inevitable un aumento temporal 
de personal, ya que se revisarán los resultados de dos sistemas en vez de 
uno; por ello, el diseñador debe advertirlo así al usuario. Tanto en la prue- 
ba piloto como en paralelo, es la ocasión para que se defina la fuerza del 
trabajo manual que servirá en el sistema, así como para detectar errores, 
corregirlos y reiniciar los procedimientos que se probarán en su totalidad; 
y revisar las estimaciones de tiempos del sistema hechas originalmente, 
pero a un nivel más realista. 

Revisión y evaluación del sistema. Una vez que se ha terminado con 
la prueba del sistema, el analista y el usuario deberán hacer una revisión 
y evaluación general de tal sistema en la cual consideren todos los proce- 
dimientos que intervengan en él, y comprobar si los resultados que se 
obtuvieron cumplen realmente con los objetivos establecidos en un 
principio, ya que en esta etapa se determinará en qué momento se libera 
el nuevo sistema. 
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Calendario de implantación. Es inevitable que cualquier sistema tra- 
baje bajo un calendario de actividades elaborado de antemano, en el cual 
se indiquen las actividades de cada uno de los elementos que interven- 
drán en dicho sistema, así como las Fechas en las que deberán desarrollar- 
se tales actividades. El analista del sistema debe elaborar este calendario 
donde tome en cuenta las necesidades del usuario, otras dependencias 
que intervengan y las cargas de trabajo en el computador. Una vez deter- 
minado el calendario, es importante que lo aprueben todas las dependen- 
cias que intervendrán en las actividades. Cuando el calendario esté apro- 
bado, deberá enviarse una copia a cada uno de los participantes en el 
sistema, para que las actividades que les correspondan se efectúen en los 
tiempos señalados. 


3. DOCUMENTACIÓN DEL SISTEMA 


La documentación adecuada y completa de un sistema que se desea 
implantar, mantener y actualizar en forma satisfactoria, es esencial en 
cualquier sistema de información; sin embargo, con frecuencia es la parte 
a la cual se dedica menor tiempo y atención. 

Toda persona dedicada a sistemas que haya recibido una solicitud 
para mantener o modificar un sistema del cual no se tenga ninguna 
documentación y en donde la persona que lo diseñó ya no trabaje en la 
institución, entenderá el problema que representa un sistema en tal 
situación. 

Intentar retroceder y documentar un sistema, después que ha estado 
en operación durante algún tiempo, es más costoso que hacerlo desde la 
primera vez, aun si se considera que el procedimiento de documentación 
original sea, de por sí, de alto costo. Este costo materialmente está deter- 
minado en mayor grado por el tiempo que el personal de sistemas dedique 
a la documentación, por lo que el propósito de este instructivo es estable- 
cer las normas de documentación por escrito, lo cual reporta las siguien- 
tes ventajas: 


+ Estandarización de la documentación. 
+ Facilitar el desarrollo de la misma. 
+ Ahorrar tiempo. 


Una vez que estas normas han quedado establecidas, es importante 
que se realice el esfuerzo necesario para ponerlas en práctica, puesto que, 
bajo estas bases, una buena documentación traerá consigo las siguientes 
ventajas: 
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+ Es una magnífica herramienta didáctica para nuevos miembros de la 
organización de sistemas, así como para nuevos usuarios del mismo. 
+ Es requisito básico para quien tenga la responsabilidad de su mante- 

nimiento y/o modificación. 

+ Ayuda a los analistas de sistemas que trabajan en áreas relativas, evi- 
tando traslapes y redundancia, y facilitando la integración a los 
diferentes sistemas. 

+ Asegura que el sistema se opere en forma correcta con el mínimo de 
errores. 

+ Se utilizan más eficientemente los recursos de que se dispone. 


Si se considera que por una u otra causa los sistemas deben cambiar, 
ya sea por una variación en las necesidades de información, una optimiza- 
ción de los sistemas, un cambio de objetivos o normas, ete., será necesario 
que la documentación sea actualizada por cada modificación, ya sea de 
diseño o de programación. 

Si no se tiene actualizada, esta documentación pronto será obsoleta, 
y una documentación así es peligrosa en extremo, tanto en lo referente a 
los errores que puedan producir en la operación del propio sistem: 
como por lo que respecta a los problemas que puedan resultar cuando se 
requieran modificaciones y los cambios previos no hayan sido docu- 
mentados. 

Otro aspecto importante es el nombre del sistema, el cual deberá ser 
único para cada sistema existente; dicho nombre deberá conservarse inva- 
riablemente en todos los documentos referentes a ese sistema, ya que será 
con ese nombre con el que se identificarán todos los procesos relaciona- 
dos con él. 


3.1. Carpeta administrativa 


Esta carpeta contendrá lo siguiente: 

Índice. Enunciado de cada apartado de la carpeta. 

Resumen administrativo (introducción). Es una condensación de 
todos los demás puntos que se detallan en esa carpeta y cuyo propósito es 
permitir a los altos ejecutivos enterarse en forma somera de los objetivos 
del sistema. Para elaborar este resumen no se establecen normas rígidas 
que limiten la capacidad de expresión de quien lo realice, excepto la reco- 
'mendación anterior de ser lo más breve posible. 

Planteamiento. Esta sección tiene como finalidad dejar registrados 
los antecedentes que sirvieron como punto de partida para el desarrollo 
del análisis del sistema emprendido. Por esto se deben mencionar los 
siguientes puntos: 
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+ Dependencia que requirió el sistema. 

e Personas y/o los puestos ocupados por éstas en el momento de 
requerirse el sistema. 

+ Los términos y/o medios bajo los cuales se hizo el planteamiento del 
sistema (acuerdos, disposiciones legales, memoranda, etc) 

+ Condiciones y criterios especificados que normaron el desarrollo 
del sistema. 

e Fechas correspondientes a los puntos anteriores. 


Objetivos y políticas. Aquí se dejarán establecidos los objetivos y 
políticas que debe cubrir el sistema en forma clara y precisa para evitar 
errores de interpretación. Para lograr lo anterior, se sugiere transcribir, o 
bien, anexar los documentos en los cuales los interesados fijaron dichos 
objetivos y políticas. 

En virtud de que durante la realización de la investigación por parte 
del análisis del sistema pudieron surgir objetivos secundarios, se mencio- 
nan en esta misma sección. 

Considerar que tanto los objetivos primarios como los secundarios 
fueron aprobados como tales por los interesados. Debe quedar perfecta- 
mente aclarada su prioridad; es decir, objetivos a corto plazo o inmedia- 
tos, y objetivos a largo plazo o mediatos, ya sean secundarios o primarios. 

Entradas al sistema (información por captar). En este punto 
deben especificarse los documentos fuente que inician las operaciones 
del sistema, así como la información detallada de los conceptos que serán 
los datos a captar por el sistema. Es recomendable que se anexe una copia 
de todos los documentos. 

Lo anterior es conveniente ya que, en ocasiones, al efectuarse el análi- 
sis del sistema, los documentos originales presentan ciertas deficiencias 
para captar los datos por procesar, por lo cual es necesario el diseño de 
nuevas formas para ese propósito; cuando esto suceda, con mayor razón 
deberá atenderse la recomendación de anexar dichos documentos con las 
anotaciones correspondientes. 

Además, deberán mencionarse todos los datos que en forma secunda- 
ria o lateral originan una entrada importante al sistema; como ejemplo 
están los catálogos de marcas, de artículos, etcétera. 

Salidas del sistema (resultados por obtener). Como se habrá obser- 
vado en el inciso anterior de entradas al sistema, sólo se hizo mención de 
los datos a captar por el mismo, así. como los datos laterales que pudieran 
significar una entrada. Ahora bien, siguiendo este criterio, en esta sección 
solamente se describen los resultados de mayor importancia obtenidos a 
través de todo el proceso. 

Cuando sea posible, se anexarán los documentos que contengan 
los resultados, ejemplo: listados, formas preimpresas, etc., o bien, los 
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diseños sobre dichos resultados, ejemplo: formato de un registro en 
cinta, diseños de impresión, etcétera. 

Cuando se considere de gran importancia el destino de algunos resul- 
tados, deberán registrarse las dependencia a las que serán distribuidos, y 
la utilización que harán de cada uno. 

Diagrama general de flujo del sistema. En esta carpeta aparecerá 
un diagrama que muestre en forma condensada el flujo de la información 
y de las operaciones que se realizan con esa información. 

Explicación genérica de las fases del sistema. Esta sección se 
encuentra relacionada directamente con Ja anterior; lo que ahí se muestra 
gráficamente, ahora se describe en forma genérica, explicando los proce- 
sos que se lleven a cabo en cada área o departamento, sin profundizar en 
detalles técnicos o específicos. 

Se deberán resaltar en forma preponderante las fases del proceso en 
las cuales se obrengan resultados de importancia, así como aquellas que 
requieran una supervisión especial. 

Requerimientos. Esta sección se presenta en virtud de que deben 
quedar establecidos los recursos, tanto humanos como materiales, necesa- 
rios para llevar a cabo la operación del sistema. 

Dentro de los recursos humanos, deberán tomarse en cuenta todos 
los tipos de trabajos ordinarios o especializados que se requieran, y con 
base en ello, tomar los elementos con que se cuenta o, de ser necesario, 
pensar en el reclutamiento de personal especializado si el trabajo lo 
requiere. 

Si el personal con que se cuenta debe capacitarse para los fines que se per- 
siguen, se planteará en esta sección el tipo de capacitación que habrá que dar a 
los elementos a quienes se les proporcionará, así como el tiempo que ello 
implique; en lo que se refiere a los recursos materiales, quedarán establecidos 
en esta sección los requerimientos indispensables para que se pueda poner en 
marcha el sistema, mencionando los dispositivos, archivos y papelería, ete., 
poniendo énfasis en los elementos materiales que no existan aún y que sean de 
vital importancia para llevar a cabo las funciones del sistema. 

Estimación del tiempo probable de implantación. Es necesario 
que exista una fecha probable de implantación, cuya base será la termina- 
n de cada etapa considerada dentro del desarrollo del sistema, tales 
como análisis, programación, elaboración de formas especiales, capacita- 
ción de personal, etcétera. 

Un punto importante que debe ser considerado dentro de esta sec- 
ción, es el periodo de congelación, atendiendo a las aprobaciones por par- 
te delos distintos funcionarios a quienes atañe la realización del sistema. 

En todo caso, la fecha estimada que se plantea aquí será seguramente 
una fecha tentativa que pueda ser modificada por consideraciones espe- 
ciales que se presentarán en el desarrollo del sistema. 
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Consideraciones generales del nuevo sistema. En caso de 
haber existido un sistema anterior que cubriera las necesidades que 
se pretenden satisfacer con el nuevo sistema, quedarán señaladas las 
ventajas, desventajas y pr ¡pales diferencias del nuevo sistema res- 
pecto a su antecesor, tales como ahorro de tiempo, disminución de 
costo, seguridad, flexibilidad, confiabilidad, proyección, etcétera. 


3.2. Carpeta del usuario 


Esta carpeta contendrá lo siguiente: 

Índice. Enunciado de cada apartado de la carpeta. 

Diagrama general del sistema. En la carpeta deberá aparecer un 
diagrama que muestre en forma condensada el flujo general de la infor- 
mación y de las actividades que se realicen en este sistema. 

Este diagrama utilizará los mismos nombres que se utilizaron con 
anterioridad en el diagrama que aparece en la sección correspondiente a 
la carpeta administrativa. 

Las recomendaciones aplicables en la elaboración de este diagrama 
son las mismas que se aplicaron en la elaboración del diagrama de la car- 
peta mencionada anteriormente, de preferencia deben ser iguales. 

Diagrama particular de la unidad usuaria. El diagrama representa 
gráficamente todos los pasos que se efectúan dentro del departamento del 
usuario a quien está dirigida esta carpeta. 

La simbología utilizada será la misma que la usada en el diseño del sis 
tema pero se especificarán en forma clara las operaciones a que se refieren 
estos símbolos. 

Deberán precisarse los archivos de entrada y de salida, los resultados 
obtenidos, comprobaciones, procesos manuales, etcétera. 

Explicación de las fases del diagrama particular. En esta sección 
se expondrán en forma específica y detallada todas las operaciones que 
aparecen representadas en forma gráfica en el diagrama particular del 
usuario, 

Aquí deben analizarse cada una de las fases de que consta el trabajo, 
además de señalar el proceso principal que se realiza, entrada de la infor- 
mación, obtención de un resultado parcial, envío de información a otra 
dependencia o departamento determinado, etc. Para ello debe seguirse el 
mismo orden que aparece en el diagrama particular dela unidad usuaria 

Instructivo de procedimientos. En cada carpeta de usuario existirá 
un instructivo de procedimientos que permita establecer los lineamientos 
generales con base en los cuales se desarrollará el trabajo por parte del 
usuario. 

Dicho instructivo deberá contener las normas referentes a pasos 
como: 
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Codificación. Cuando sea necesario efectuar una codificación, aquí 
se darán los criterios acerca de cómo se desea llevar a cabo. Ello implica 
conocer el documento fuente y la hoja donde se vaciará. En caso de ser 
necesario, también se darán las claves y normas conducentes al logro de 
los fines que se pretenden con la codificación. De ser posible, se anexarán 
el documento fuente, o una copia del mismo, y una hoja de vaciado. 

Facturación. Cuando el proceso implica el manejo de documentos 
que pudieran extraviarse, deberán existir una factura o facturas que 
amparen el envío, manejo, recepción, etc., de dichos documentos. En esta 
sección se establecerán los tipos de facturas que se definan, los documen- 
tos que son amparados en esta fase, así como la fecha. Se anexarán copi 
de las facturas. 

Envío. Debido a que el usuario va a producir resultados que deberán 
trasmitirse a otras dependencias o departamentos, es necesario conocer a 
dónde se enviarán los resultados obtenidos por ese usuario, volumen esti- 
mado, periodicidad con que ello se efectúe y forma de envío. 

Confirmación de listados. A veces será necesario verificar los listados 
obtenidos en algún otro departamento, contra los documentos fuente. El 
usuario encargado de esta actividad deberá tener una guía para comparar 
ambos documentos. La forma en que dicha comparación se lleve a cabo, 
así como los campos esenciales para verificar, quedarán establecidos en 
este párrafo. 

Condiciones anormales. Todas las condiciones anormales no previs- 
tas en los párrafos mencionados, deberán quedar aclaradas aquí. Entre 
otras podrían ser: proceso por seguir en caso de encontrar errores, consul- 
tas a otras dependencias en caso necesario, etcétera. 

Solicitudes de modificaciones y trabajos especiales. Cuando se 
analiza el sistema propuesto, es posible que no se detecten situaciones 
especiales que afecten su diseño. 

Al detectar estas situaciones, es posible que se origine una solicitud 
de modificaciones al sistema donde se señalen los procesos que se desean 
modificar, las causas por las que se han planteado y las posibilidades de 
llevarse a cabo, así como las ventajas y desventajas que las modificaciones 
implican. 

En caso de que durante el diseño del sistema se detecte la posibilidad 
de obtener algún resultado no establecido con anterioridad, se especifica- 
rá en esta sección el tipo de trabajo que se desea, la fase en la cual puede 
obtenerse, y todas las demás observaciones relacionadas con ese trabajo 
especial, por ejemplo: que al vaciarse a una hoja de codificación los datos 
de un documento fuente, se pueda obtener un catálogo de productos 
especiales, etcétera. 

En ambos casos, ya se trate de una modificación o de un trabajo espe- 
cial, deberán llevar la fecha en que se haya planteado. 


168 CAP. 17, ANÁLISIS, DISEÑO Y.. 


Caducidad de documentos fuente y destino final. En ocasiones, 
ambas tienen por ley un periodo de retención y un destino específico; en 
esta sección debe quedar claramente designado el espacio de tiempo Con 
que se cuenta para manejar los documentos fuente y el lugar al que 
habrán de destinarse. 


3.3. Carpeta para captación de datos 


Esta carpeta contendrá lo siguiente: 

Índice. Enunciado de cada apartado de la carpeta. 

Diagrama general de flujo del sistema. En la carpeta aparecerá un 
diagrama que muestra en forma condensada el flujo de la información y 
de las operaciones que se realizan en este sistema, Este diagrama utilizará 
los mismos símbolos y nombres que se utilizaron con anterioridad en el 
diagrama que aparece en la sección correspondiente de la carpeta admi- 
nistrativa. 

Las recomendaciones aplicables en la elaboración de este diagrama, 
son las mismas que se aplican en la elaboración de la carpeta mencionada, 
de preferencia deben ser iguales. 

Diagrama particular a detalle. El diagrama particular a detalle será 
la representación de todos los pasos que sigue la información dentro del 
departamento de captura de datos. 

La simbología que se utilizará será la misma que la usada en el diseño 
del sistema. 

En este diagrama aparecerán todas las operaciones que se efectúen 
con o sobre la información, tales como: recepciones, comprobaciones y 
revisiones, procesos manuales, perforación, verificación, uso de dispositi- 
vos especiales como: pantallas de video, key-tape, así como producción de 
listas de prueba, envíos, etcétera. 

Explicación de las fases del diagrama particular. En esta sec- 
ción se explican en forma específica y detallada las operaciones que 
aparecen representadas en forma gráfica en el diagrama particular de 
detalle. 

Siguiendo el orden que aparece en el diagrama anterior, se proce- 
derá a explicar en forma detallada cada una de las operaciones que se 
efectúen, poniendo énfasis en la obtención de resultados parciales 
como: listados de prueba, archivos de paso en cinta o disco, envío de 
listados, recepción de formas especiales para vaciado de información, 
etcétera, 

Además, deberá darse una explicación clare y precisa sobre las cifras 
de control que se hayan establecido para cada fase del proceso. 

Fuente de los datos por captar. En esta sección aparecerán las fuen- 
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tes de donde proceden los datos que se van a captar, tales como el departa- 
mento en que se origina la información y el destino de ésta para su proceso. 

Al mencionar el origen de la información, éste variará según la situa- 
ción particular de un sistema, podría ser el cliente, una oficina de cobran- 
za, un departamento de contabilidad, etcétera. 

Instrumentos utilizados para la captación. Aquí deben mencio- 
narse todos los medios con los cuales se ayuden para captar la informa- 
ción, tales como: formas especiales, solicitudes, avisos, hojas de vaciados, 
listados de prueba, declaraciones, etcétera. 

En caso de que la captación de datos se efectúe mediante dispositivos 
especiales, será necesario incluir aquí los instructivos correspondientes a 
dichos dispositivos, así como también establecer los tipos de dispositivos, 
características, funciones, etcétera. 

Formatos donde aparecen los datos. En virtud de que los datos 
serán procesados posteriormente, deben conocerse y establecerse los for- 
matos en los cuales aparezcan los datos, tanto al captarse como después de 
ser procesados. 

Deberán anexarse los formatos donde se encuentra la información y, 
de ser posible una copia de los documentos en que aparezcan (facturas, 
cheques, etc.). Dichos formatos deben indicar la naturaleza de los datos y 
los nombres con que se designan, así como las posiciones en que se 
encuentran, longitud, etcétera. 

Cuando la información aparezca en tarjetas perforadas o en cualquí 
dispositivo magnético, se anexarán formatos especiales que existan para 
marcar el arreglo de los datos. 

Transformaciones de la información, previas a su procesamiento 
electrónico. En esta sección quedarán asentadas todas las transformacio- 
nes que la información haya sufrido con anterioridad a su procesamiento 
electrónico. 

Una vez que se ha captado la información, ésta puede entrar a dil 
rentes procesos antes de su transformación electrónica; dichos procesos 
deberán mencionarse aquí, haciendo resaltar aquellas actividades u ope- 
raciones que den como resultado una transformación de la información. 
Un ejemplo podría ser una sumarización de información, o una clarifica- 
ción de datos. 

Instructivo de situaciones anormales. Existirá un instructivo de 
situaciones anormales que permita prever el curso de las actividades en 
caso de detectarse situaciones anormales. 

Este instructivo marcará cuándo una operación se encuentra fuera de 
los estándares preestablecidos, y la acción que debe tomarse en cada caso. 

Las entregas al centro de cómputo. En esta sección deberá existir un 
calendario que establezca los horarios y la periodicidad de las entregas al área 
de operación, la recepción por parte del centro de cómputo, el envío de fac- 


170 CAP. 17. ANÁLISIS, DISEÑO Y... 


turas, la forma de verificar las cifras de control, tanto de la entrada de infor- 
mación como de salida, la duración del proceso y las fechas probables de 
entrega de resultados; se deben mencionar también los conductos por los 
cuales se hagan las entregas al área de operación. 

Caducidad de los datos fuente. Debido a los grandes volúmenes de 
información con que se trabaja, es necesario establecer por escrito la fecha 
de caducidad de los documentos fuente y el fin a que han de destinarse, 
ya sea para su destrucción, devolución o conservación en un archivo 
determinado. 

Si se destina a un archivo determinado, ello implica llenar una forma 
que indique el volumen, fecha de entrega, fecha de caducidad y destino 
final al cumplirse el lapso en que han de ser archivados. 


3.4, Carpeta de programación 


Esta carpeta contendrá lo siguiente: 

Índice. Enunciado de cada apartado de la carpeta. 

Diagrama general. En la carpeta aparecerá un diagrama que mues- 
tra en forma condensada el flujo general de la información y de las activi. 
dades que se realicen en este sistema. 

Este diagrama utilizará los mismos símbolos y nombres que se utiliza- 
ron con anterioridad en el diagrama que aparece en la sección correspon. 
diente a la carpeta administrativa. 

Las recomendaciones aplicables en la elaboración de este diagrama 
son las mismas que se aplicaron en la elaboración del diagrama de la car- 
peta administrativa, de preferencia deben ser iguales. 

Diagrama de flujo del proceso electrónico. En este diagrama se pre- 
sentarán gráficamente todos los pasos que se siguen en el área de opera- 
ción en forma detallada y especifica, desde la entrada de información has- 
ta la obtención de resultados finales. 

Para ello es necesario que aparezcan en dicho diagrama todas las ope- 
raciones y dispositivos requeridos, donde se identifiquen todas ellas por el 
uso de la simbología utilizada en el área de sistemas, se marcará cada una 
de las fases (conversión, copíado de archivos, impresión de listado, etc.) 
por una leyenda que así lo explique, además, dentro del símbolo utilizado 
para el proceso, irá la clave del programa correspondiente. 

También aparecerá en forma clara y precisa el nombre de los archivos 
que entran al proceso, y deberá ponerse una leyenda que, de ser necesa. 
rio, aclare la situación especial de un archivo, como podría ser el tipo de 
acceso que tendrá. 

Descripción general de las fases. En vista de que, por lo gene- 
ral, una fase del proceso, se identifica con el programa que lleva a 
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cabo esa parte determinada, no es necesario explicar en forma detalla- 
da todas las fases que se encuentran incluidas en el diagrama general 
de flujo, y será suficiente con mencionar la fase de que se trata, el pro- 
grama que la identifica y, si fuera necesario, algunas características 
esenciales de ese programa. 

Por cada programa con que cuenta el sistema se incluirá la siguiente 
documentación: 

Índice. Enunciado de cada sección. 

Definición del programa. Esta sección deberá llevar el nombre o 
clave del programa, fecha y el sistema a que pertenece, estableciendo 
por escrito los objetivos inmediatos del programa, los dispositivos en 
donde se encuentran contenidos los archivos de entrada, etiquetas, 
posiciones por registro, factor de bloque y clasificación, y también los 
dispositivos donde se desea contener los archivos de salida, etiquetas y 
posiciones por el registro. 

Tambien contendrá la explicación del proceso para obtener los resul- 
tados deseados en forma detallada, sobre todo en los casos en que se desea 
un proceso estrictamente señalado (cálculo del impuesto a determinados 
causantes, algoritmo del cálculo del homónimo, etc.) y las cifras de con- 
trol que se desean obtener. 

Diagrama de bloque. Es una representación de la lógica que se utiliza 
para obtener los resultados de un programa determinado. 

La elaboración del diagrama de bloque se hará mediante el uso de 
simbología establecida, procurando ser lo más explícito posible en todos y 
cada uno de los pasos que aquí se definan. 

Este diagrama debe contener todas las operaciones a considerar en el 
programa; deben coincidir los nombres de archivos, registros, secciones, 
etc., los cuales aparecerán en la codificación del programa. 

El diagrama del bloque se identifica con los datos de clave de aplica- 
ción, clave del programa, fecha de elaboración y hojas de que consta. 

Diseño de formatos de registro e impresión. Como complemento 
necesario de la definición, existen los formatos de registro e impresión. 
Como los registros pueden estar contenidos en tarjetas perforadas, o en 
cualquier otro medio, aquí se mencionará el archivo de que se trata, así 
como el dispositivo que lo contiene, utilizando los siguientes elementos, 
tanto para modo de entrada como de salida. 


a) Registros múltiples. En caso de existir dos o más tipos de regis- 
tros para el programa, se recomienda usar el formato múltiple; 
podrá usar el layout de campos, o bien, dibujarlo. 

En cualquier caso deberá contener la clave del programa (que 
servirá para su identificación), así como también la clave de la 
aplicación. 
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b) 


d) 
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Se marcarán y escribirán con claridad todos y cada uno de los 
campos. 

En caso de que contenga claves, se deberá anotar una tabla que 
explique el significado de las mismas, esto deberá quedar en la mis- 
ma hoja en que se hizo el formato. 

Formato de registro. Esta forma se usará para diseño de registros, 
tanto en cinta magnética como en dispositivos de acceso directo, y 
se debe emplear como a continuación se indica: 


e Clave de programa. La correspondiente. 

+ Dispositivo de almacenamiento. Se pondrá el nombre genérico 
del dispositivo, ejemplo: cinta magnética, disco, etcétera. 

» Salida, Se marcará si se trata de un archivo de salida. Cuando el 
mismo formato corresponde tanto a entrada como a salida, se 
marcará en ambos casos. 

e Fecha. Día, mes y año de cuando se entrega el instructivo, o 
cuando el analista diseñó el formato. 

+ Notas. Se anotarán las características generales del archivo, como 
son: nombre, etiquetas, número de posiciones por registro, factor 
de bloque, organización, llave de acceso, ete., así como las que 
consideren pertinentes. 


Impresión. Se empleará el diseño más adecuado de acuerdo con las 
necesidades de la impresión, pero procurando anotar las posicio- 
nes que ocupan los distintos conceptos por imprimir dentro de las 
132 posiciones disponibles, para lo cual se recomienda usar el 
layout de impresión. 

En el formato de impresión se anotan: 


+ Los títulos deseados. 

+ El formato de la fecha. 

+ Los campos deseados por sacar a impresión. 
+ El espaciado entre una línea y la siguiente. 
+ Impresión de signos especiales. 

+ Posiciones de los campos a imprimir, 

+ Pie de página, etcétera. 


Descripción de campos. Para todos los formatos de registros, es 
recomendable usar la estructura de renglones: 


e En el primer renglón se escribirá el nombre correspondiente a 
cada campo y/o subcampo. 

+ En el segundo renglón se escribirán las posiciones de inicio y fin 
del campo o subcampo. 
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« En el tercer renglón se especificará el número de posiciones que 
ocupa dicho campo dentro del registro, para lo cual, según el tipo 
de caracteres que contendrá cada campo, se adopta la siguiente 
anotación convencional: 


— Alfabético: An. 
— Alfanumérico: Xn. 
— Número decimal: Zn. 
— Empacado: Pn. 


Donde n es número de posiciones, ejemplo: 
A28,X10,29,P4 


Listado de la última compilación. Para tener un respaldo del progra- 
ma que se encuentra en tarjetas (o en cualquier otro medio), deberá con- 
tarse con un listado que se haya obtenido inmediatamente después de la 
última compilación del programa, y el cual se identifique con la clave del 
programa, clave del sistema y fecha en que se obtuvo. 

Cláusulas de lenguaje de control de trabajos (JCL). Deberá contarse 
con un listado de las cláusulas de control para que el programa pueda ser 
utilizado en cualquier momento. Aun cuando no se cuente con las cláu- 
sulas de control, bastará con recurrir a este listado para elaborarlas en for- 
ma inmediata. 

Lo anterior es necesario en vista de que los programas se encuentran 
catalogados; a fin de ejecutarlos debe existir un juego de cláusulas para 
iniciar el programa y otro juego para su reinicio. 

El reflejo de esos juegos de cláusulas serán los propi: 
cláusulas de control. 

Cifras de control. En esta sección se establecen por escrito todas aque- 
llas cifras necesarias para conocer la actividad de un programa. 

Serán tantas como sean necesarias, con una longitud variable que 
será determinada por los volúmenes estimados con los que trabajará el 
programa. 

En esta sección quedarán escritos los conceptos para interpretar las 
cifras de control, así como las fórmulas que permitan checar dichas cifras 
para hacer una evaluación y saber si los resultados obtenidos en ellas son 
correctos. 

Una copia de la prueba final del programa servirá para anexarla al ins- 
tructivo de operación al cual nos referimos más adelante. 
istado de datos prueba. Esta sección está formada por los listados de 
los datos prueba que se hayan utilizado para la prueba del programa, ya 
que servirán como referencia en caso de que desearan verificarse con pos- 
terioridad los resultados obtenidos en las pruebas. 


istados de las 
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Resultados de la última prueba del programa. Los resultados a que se 
refiere esta sección, son los listados de impresión obtenidos durante la 
última prueba, verificando que los resultados que aquí se muestran coin- 
cidan en longitud, posiciones, espaciado, etc., con lo especificado en el 
formato de impresión, al igual que el formato de la fecha, el pie de página, 
los títulos, etcétera. 

En caso de que no se obtengan los resultados impresos, lo único que 
se verificará serán las cifras de control (formato, leyenda, etc.), con excep- 
ción de aquellos casos en los que se haya especificado que no se obtendrán 
cifras de control. 

Todos los documentos inherentes al programa y que no se hayan 
incluido en los párrafos anteriores, se agregarán como anexos al final del 
resultado de la última prueba, marcándose también con la clave del pro- 
grama, la fecha y una leyenda que identifique cada anexo. 


3.5. Carpeta de operación 


Esta carpeta contendrá lo siguiente: 


Índice. Enunciado de cada apartado de la carpeta. 

Diagrama general. En la carpeta aparecerá un diagrama que muestra, 
en forma condensada, el flujo general de la información y de las actividades 
que se realicen en este sistema. 

Este diagrama utilizará los mismos símbolos y nombres que se utilizaron 
con anterioridad en el diagrama que aparece en la sección correspondiente 
de la carpeta administrativa. 

Las recomendaciones aplicables en la elaboración de este diagrama 
son las mismas que se aplicaron en la elaboración del diagrama de la car- 
peta ya mencionada, de preferencia deben ser iguales. 

Diagrama de flujo del proceso electrónico. Ën este diagrama se pre- 
sentarán gráficamente todos los pasos que se siguen en el centro de 
cómputo, en forma detallada y específica, desde la entrada de la informa- 
ción hasta obtener los resultados finales. 

Para ello es necesario que en dicho diagrama aparezcan todas las 
operaciones y dispositivos requeridos, los cuales deben identificarse 
con la simbología utilizada en dicho centro; se marcará cada una de 
las fases (conversión, copiado de archivo, impresión de listados, etc.) 
con una leyenda que así lo explique, además, dentro del símbolo utili- 
zado para cada proceso deberá ir la clave del programa con que lleve a 
cabo este proceso. 

También aparecerá en forma clara y preeisa el nombre de los archivos 
que entran en el proceso; y en cada caso se pondrá una leyenda que de ser 
necesario aclare la situación especial de un archivo. 
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Descripción general de las fases. En vista de que, en general, una 
fase del proceso se identifica con el problema que lleva a cabo esa parte 
determinada, no es necesario explicar en forma detallada todas las fases 
que se encuentran incluidas en el diagrama general de flujo; bastará con 
mencionar la fase de que se trata, el programa que la identifica y si fuera 
necesario, algunas características esenciales de ese programa. 

Caducidad de archivos. En este punto el analista deberá especificar 
la caducidad de los archivos que maneje el sistema, y tomar en considera- 
ción los respaldos necesarios. 

Asimismo, habrá un instructivo de operación por cad programa exis- 
tente en el sistema, con lo siguiente: 

Diagrama general de entradas-salidas. En la primera hoja del ins- 
tructivo pueden existir tantos diagramas como opciones tenga el progra- 
ma correspondiente. Se llena de la siguiente manera: 


+ Nombre o clave del programa. Se anotará el nombre o clave que el 
analista asignó al programa, éste debe ser el mismo que aparezca en 
la tapa de la carpeta del instructivo individual del programa. 

e Sistema. Nombre del sistema. 

«+ Analista programador. Iniciales de los nombres y apellidos paternos, 
tanto del analista como del programador. 

« Fecha. Día, mes y año en que se elabora el instructivo. 

e Entradas/Salidas. Se conectarán a la unidad central, por medio de 
líneas, los dispositivos a utilizar, y se llenarán las especificaciones 
correspondientes a los archivos particulares. En el caso de la impre- 
sora, se anotará a su lado la forma, medida y tantos por utilizar, así 
como la especificación de control de salto. 

+ Observaciones. Se anotarán condiciones especiales de arranque, lo 
que hace el programa, así como la opción de que se trata cuando 
existan más de una o, en su caso, cuando lo que se pretende anotar 
sea extenso, se anexará una sección de aclaraciones especiales, don- 
de se anote la existencia de dicha sección. 


Mensajes. Si el programa, como caso excepcional, requiere enviar 
mensajes por consola, se anexará una forma de mensajes, que debe llenar- 
se de la siguiente manera: 


+ Clave del programa. La que corresponda. 

» Fecha. Día, mes y año de la elaboración del instructivo. 

» Hoja. Número progresivo que le corresponde dentro del instructivo. 

+ Mensaje. Texto del mismo, o bien su identificación cuando así se 
use. (Esto será por cada mensaje que envie el programa). 

« Causa. Lo que origina en el proceso que sea enviado el mensaje, se pue- 
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de usar la palabra autoexplicativo cuando sea así el mensaje y se haya 
escrito en esta forma. 

n. Lo que debe hacer el operador cuando se presente esta con- 
es posible que también el mensaje sea autoexplicativo a este 
respecto. 


Cláusulas de lenguaje de control de trabajos (JCL). Deberá contar- 
se con un listado de las cláusulas de JCL para que el programa se pueda 
utilizar en cualquier momento; así, cuando no se cuente con estas cláusu- 
las de control, bastará con recurrir a este listado para elaborarlas inmedia- 
tamente, 

Lo anterior es necesario porque los programas se encuentran catalo- 
gados, y a Fin de ejecutarlos debe existir un juego de cláusulas para iniciar 
el programa y otro juego para su reinicio, si el programa contiene la rutina 
de check point. 

El reflejo de esos juegos de cláusulas serán los propios listados de las 
cláusulas de control. 

Aclaraciones particulares de cada La finalidad de esta 
sección es dejar por escrito y a manera de instrucciones para operación 
todas las condiciones que, por su naturaleza, se consideren como especia- 
les dentro de un programa particular y que, por lo mismo, deberán aten- 
derse en forma preponderante. 

Para ello, en el diagrama general de entradas-salidas se hará la anota- 
ción que indique la existencia de la sección de aclaraciones. Resulta ocio- 
so pero oportuno insistir en que no todo programa va a requerir esta sec- 
ción, ya que las “condiciones especiales” que se mencionan son a nivel 
operacional y no de lógica interna. 

Cifras de control. En esta sección se establecerán por escrito todas 
las cifras que sean necesarias para conocer la actividad de un programa, 
teniendo una longitud variable que se determinará por los volúmenes 
estimados de datos con los que trabajará el programa. 

En esta sección quedarán escritos los conceptos para interpretar las 
cifras de control que aquí aparezcan, así como las fórmulas que permitan 
verificarlas para hacer una evaluación y saber si los resultados obtenidos 
en estas cifras son correctos. 

Se podrá usar una copia exacta de lo que ya exista en la carpeta de pro- 
gramación. 

Diseños de impresión. En esta carpeta de oper: 
formato de resultados en el cual se mostrarán: 


n debe existir un 


» Títulos deseados. 
+ Subtítulos. 
+ Formato de la fecha. 
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+ Campos deseados para sacar la impresión. 
e Espaciado entre una línea y la siguiente. 
+ Impresión de signos especiales. 

+ Posiciones de los campos a imprimir. 

+ Pie de página, etcétera. 


En el caso particular de forma preimpresa deberá anexarse un ejem- 
plar que muestre el diseño ya impreso, que facilite el centrado de la mis- 
ma; no hay que olvidar las especificaciones de control de salto. 

Los resultados impresos obtenidos por el programa deberán ajustarse 
a los especificados en el formato de impresión. 

Formatos de registro. En esta carpeta deberán existir los formatos de 
registro de entradas y salidas que utilice el programa. 

Distribución de resultados. Para hacer más fluido el trabajo que se 
realice en determinada aplicación, es necesario conocer de antemano los 
lugares hacia donde se van a canalizar los resultados obtenidos, éstos son: 


+ Bode 
» Archivo. 

e Cintoteca. 
+ Usuarios. 


Por escrito, quedará la cantidad y lugares hacia los cuales se hará la 
distribución de los resultados que se hayan obtenido. 

Todo cambio en el sistema deberá ser reflejado en su respectiva docu- 
mentación para tenerla actualizada. 

Las carpetas referidas anteriormente son las requeridas para lograr 
una buena documentación del sistema en cuestión. Sin embargo, deberá 
considerarse como un tipo de documentación importante para la instruc- 
ción del personal que maneja el sistema; por lo tanto, el siguiente punto 
deberá ser necesario. 


3.6. Instrucción sobre manejo del sistema 


Debido a que el analista es quien tiene un conocimiento pleno del sis- 
tema, es la persona más adecuada para impartir la instrucción que sea 
necesaria para el manejo del sistema. Esta instrucción debe darse a todas 
las personas que intervengan en el manejo del mismo, para que sepan 
manejar la información que a cada uno le corresponde, y para hacerles 
sentir la importancia de sus actividades y el objetivo que se persigue con el 
sistema, así como las repercusiones que puede tener un mal manejo de la 
información. 
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Ahora bien, como los instructivos facilitan el entrenamiento y la 
capacitación del personal, es también labor del analista elaborarlos. 

La elaboración de manuales facilita el entrenamiento y la capacitación 
del personal. A continuación se mencionan otros tipos de instructivos. 


3.7. Instructivos de procedimientos manuales 


3.7.1. Instructivo de codificación y manejo 
de archivos 


Este instructivo indica cuáles datos deben captarse, de qué documen- 
tos fuente, en qué orden, el lugar del cual deben tomarse, bajo qué condi- 
ciones, etc.; debe contener como mínimo: 


» Introducción. 

+ Generalidades. 

+ Documento fuente. 

e Datos a captar y condiciones (ejemplos). 
+ Elaboración de cifras de control. 

+ Cuotas por cubrir. 

+ Calendario de entrega. 


3.7.2, Instructivo de realimentación 
de información 


Debido a que la información presenta diferentes condiciones de error 
y al volumen de los mismos, el analista debe estudiar con cuidado cuál 
será el método para eliminar o corregir las inconsistencias que se presen- 
ten. Este método debe ser económico, práctico y cumplir con todas las 
condiciones posibles para la realimentación de correcciones. 

Los rechazos o señalamientos de inconsistencias se hacen por lotes, 
facturas, documentos o campo. La corrección y realimentación, por tan- 
to, pueden hacerse en la misma forma. 

Es el instructivo que para este fin se elabore, el que indicará los 
medios más apropiados. Este instructivo deberá contener como mínimo: 


+ Introducción. 

+ Generalidades. 

+ Causas del rechazo. 

+ Formas de corrección. 
+ Cuotas a cubrir. 

« Calendario de entrega. 


4. OPERACIÓN DEL SISTEMA 


La operación de un sistema es la parte que, dependiendo de la consis- 
tencia del sistema y de su documentación, será la que integralmente arro- 
jará los resultados producto del mismo. Este manejo será regulado por los 
siguientes elementos: 


4.1. Calendario de recepción de información 
y entrega de resultados 


Debido a que es necesario prever las cargas de captación de datos y 
responsabilizar al usuario de la entrega oportuna de su información, se 
debe elaborar un calendario de recepción de información y de entrega de 
resultados, porque también el centro de cómputo está obligado a entregar 
resultados en forma oportuna para lograr la continuidad en el trabajo de 
los usuarios. 

El calendario deberá contener lo siguiente; 


+ Áreas que intervienen en el sistema. 

+ Actividades por realizar en cada área. 

+ Duración de la actividad (tiempo estimado y tiempo real). 
+ Observaciones. 


El calendario acordado se debe respetar; de lo contrario, las áreas 
que intervienen en el sistema se verían afectadas en la planificación de 
su trabajo. 

El calendario acordado debe darse a conocer a las distintas áreas, y 
cada una de ellas debe aprobarlo por escrito. 

Existen algunos resultados estimados por el sistema o algunos resulta- 
dos especiales no considerados dentro de éste, que no podrán sujetarse al 
ciclo de un calendario por ser emitidos en forma exclusiva a petición del 
usuario. Estos resultados se manejarán por órdenes de proceso y las fechas 
de entrega de resultados se acordarán después de recibir la solicitud del 
trabajo, previa aprobación de ésta. 


4.2. Caducidad y respaldo 
de información 


Al tomar en cuenta los grandes volúmenes de información que se 
manejan, es necesario establecer por escrito la fecha de caducidad de la 
información, y el fin a que ha de destinarse, ya sea para destruirla o para 
archivarla. Existen tres tipos de caducidades: 
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Caducidad de información documental. Esta caducidad queda 
sujeta a la reglamentación de la dependencia del usuario respectivo, que 
en la mayoría de los casos es el depositario y responsable de dichos docu- 
mentos. 

En los casos de excepción, el usuario respectivo, así como el analista 
responsable, determinarán en conjunto la fecha de caducidad de la infor- 
mación documental, ésta es normalmente cada tres actualizaciones del 
archivo afectado. 

Caducidad de información captada. Esta información no es sino la 
traducción a medios procesables de la información documental. 

Los archivos en documentos se podrán dar de baja cada tres actualiza- 
ciones del archivo afectado en dispositivos magnéticos, ya que sirven 
como respaldo de éstos. 

Caducidad de información magnética. La caducidad de informa- 
ción contenida en dispositivos magnéticos se determinará cada tres actua- 
lizaciones del archivo base, ya que sirven como respaldo de éste en caso de 
ser necesario repetir algún proceso. Los tipos de archivo contenidos en 
dispositivos magnéticos pueden ser: 


+ Archivos base. Son archivos base los generados por el propio sistema 
y que servirán para obtener datos estadísticos o resultados del mismo. 
La caducidad de estos archivos variará de acuerdo con las actualiza- 
ciones que sufra el mismo. Usualmente es cada tres actualizaciones, 
ya que sirve de respaldo al archivo actualizado. Algunos archivos base 
llegan a convertirse, al cierre de determinado ejercicio, en archivos de 
consulta, por lo que se les dará caducidad histórica. 

» Archivos de paso. Son aquellos archivos que, como su nombre lo 
indica, sólo intervienen en alguna fase de un proceso. La caducidad 
de estos archivos por lo general será inmediata una vez validado el 
proceso mediante las cifras de control correspondientes. Este tipo 
de archivos normalmente se generan de programas de utilidad 
(Sort, Merge, Selector, etc.). 

+ Archivos de movimientos. Son aquellos archivos que afectan de 
alguna manera a los archivos base o de consulta. La caducidad 
de estos archivos será cada tres actualizaciones, ya que sirven de 
respaldo a los archivos actualizados. 


4.3. Regulación de la operación 
del sistema 


Para lograr que un sistema funcione con alto grado de confiabilidad, es 
necesario; además del buen diseño del sistema, tener una regulación opera- 
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cional del mismo; es decir, ejercer una constante vigilancia sobre los resulta- 
dos que se obtienen, utilizando para ello los siguientes elementos: 

Cifras de control. Las cifras de control deben dar la garantía a un 
analista de los buenos resultados obtenidos en un proceso; además, 
deben ser precisas, claras y lógicas, para llegar a una validación rápida 
y confiable. 

Tiempos de proceso. Es necesario considerar los tiempos de proceso 
dentro de un sistema, porque los procesos que no justifican un consumo 
de tiempo considerable se disparan en éste, y es indispensable revisar el 
programa afectado y buscar su optimización. 

Si esta política se aplica a un sistema en su conjunto, se reducirán los 
tiempos de proceso, y en consecuencia, las horas-máquina ocupadas por 
un sistema. 

Puntos de control. Un sistema debe tener puntos de control estri 
tos, dado el manejo de que es objeto la información por procesar. Estos 
puntos de control son la facturación de documentos por captar, y poste- 
riormente, de los registros capturados, para verificar estas cifras contra las 
de control obtenidas electrónicamente y cualquier control que verifique 
la validez de los procesos. 

Oportunidad de resultados. Los resultados obtenidos por un siste- 
ma se deben entregar en forma oportuna y veraz; si no es así, serán inúti- 
les para el usuario. 


Mantenimiento de la biblioteca 
de documentación 
de sistemas 


Cuando se diseña un sistema debe hacerse considerando que debe ser 
permanente en una institución, no así las personas; por lo que es necesa- 
rio crear una biblioteca de sistemas en la cual existirán tantas documenta- 
ciones de sistemas, como sistemas existan. 

Todo sistema es viable de optimizarse o modificarse, por lo que es 
necesario actualizar su documentación; cuando así sea podrían afectarse 
las siguientes carpetas: 


+ Carpeta administrativa. 

« Carpeta del usuario. 

« Carpeta de captación de datos. 
« Carpeta de programación 

« Carpeta de operación. 
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Dentro de la biblioteca, cada sistema debe estar integrado por las car- 
petas mencionadas; asimismo, es recomendable agrupar sistemas por 
áreas de servicios similares, para mayor facilidad de consulta. 


4.5. Variaciones de operación 
(permitidas por el sistema) 


Cuando un sistema ya ha sido implantado, es posible que surja la 
necesidad de variar la operación sin que afecte al sistema en sí. Estas varia- 
ciones podrán ser: 


+ Número de copias impresas. 

+ Destino de resultados. 

+ Distribución de resultados. 

+ Rangos en tarjetas parámetros. 
+ Modificaciones de encabezados. 


4.6. Distribución de resultados 


La distribución de resultados se hará de acuerdo con las necesidades 
del usuario, donde se determine en forma conjunta el modo de hacerse. 
La distribución de resultados podrá ser: 

Directamente al usuario. Aunque la entrega de resultados se haga 
por medio de una oficina de servicios, los resultados son enviados directa- 
mente al usuario, siendo éste el que les dé el destino final. 

Por medio de la oficina de servicios. En este tipo de entrega se deci- 
de previamente el destino de los resultados obtenidos por un sistema. Es 
decir que la oficina de servicios se encargará de distribuir los resultados 
obtenidos por un sistema de acuerdo con lo establecido en éste. 

Por correo. Este tipo de entrega puede variar en su procedimiento; es 
decir, se le pueden enviar los resultados bajo responsabilidad de la oficina 
de correos según lo crea conveniente, o bien, el centro de cómputo se 
puede encargar de rotular los envíos y hacerlos llegar a su destinatario por 
embarque particular. 


5. MANTENIMIENTO 


Una vez implantado un sistema, es necesaro darle mantenimiento 
para cerciorarse de su buen funcionamiento y adaptación a las necesida- 
des del momento, ya sean del sistema electrónico o de recursos técnicos. 
A un sistema se le debe dar mantenimiento básicamente por actualizacio- 
nes del sistema o por racionalización del mismo. 
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Un sistema se puede actualizar por: 

Nuevos resultados. Los nuevos resultados dentro de un sistema pue- 
den afectarlo, desde los procedimientos manuales, el proceso electrónico 
del mismo, los recursos humanos, o sólo algunos de éstos, y es necesario 
actualizar el sistema según se requiera. 

Modificación a resultados existentes. Como en el punto anterior, 
un sistema se puede ver afectado en cualquiera de sus puntos; por lo tan- 
to, será necesario actualizar el sistema, incluso por disposiciones legales. 

Variaciones de procesos y/o de recursos. Las variaciones de proce- 
sos pueden ser: 


+ Entradas. Las variaciones en las entradas de un sistema pueden estar 
relacionadas con el cambio del documento fuente y/o con los recur- 
sos de captación, generándose una variación en el sistema; por lo 
que es necesario actualizarlo, ya sea parcial o totalmente. 

+ Salidas. Las variaciones en las salidas de un sistema pueden estar 
relacionadas con las variaciones de entrada y/o con las variaciones 
de operación. Es decir, si la creación de un nuevo resultado, o la 
modificación a otro ya existente, afectan las entradas de un sistema, 
lógicamente afectarán las salidas del mismo, y en consecuencia su 
operación, por lo que es necesario actualizar el sistema, ya sea par- 
cial o profundamente. 

+ Operación. Las variaciones de operación son producto de las varia- 
ciones de entradas y/o salidas de un sistema, o bien por fallas de pro- 
ceso; por lo que es necesario actualizarlo. Habrá variaciones de ope- 
ración en donde no será necesaria la actualización del sistema, 
únicamente se hará un ajuste en la fase afectada. 


Las variaciones de recursos de un sistema pueden ser: 


+ Humanos. En la implantación de un sistema se deben indicar los 
recursos humanos necesarios para el manejo del mismo. La varia- 
ción de este recurso puede repercutir en el buen funcionamiento 
del sistema; por lo cual será necesario realizar los ajustes correspon- 
dientes para que estas variaciones no interfieran en su funciona- 
miento. 

« Materiales. Los recursos materiales de que dispone un sistema están 
estrechamente ligados con los recursos materiales de que disponen 
las unidades que intervienen en él. Al cambiar el tipo de los recursos 
materiales de las unidades, un sistema podrá variar a fin de adaptar 
el sistema a estos nuevos recursos, sin que esto afecte los objetivos 
originales. 
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Documentación. Las variaciones que sufra un sistema por actualiza: 
ción, lógicamente repercutirán en la documentación del sistema, ya que 
ésta servirá de consulta para cualquier persona relacionada con el mismo. 

Las actualizaciones de documentación del sistema deberán efectuarse 
a la mayor brevedad después de ocurrida la variación, de lo contrario, Ile- 
ga un momento en que la documentación no corresponde a la realidad o 
se olvida la modificación. 

Regionalización. Al actualizar un sistema se debe investigar si esta 
actualización es aplicable al sistema implantado en las regiones. El con. 
cepto de regionalización es común en empresas gubernamentales, ban. 
cos, y en general, en empresas que implantan los sistemas centrales en lay 
demás regiones del interior del país en donde también dan servicio. 

Racionalización. Todo sistema debe estar sujeto a una racionaliza- 
ción, es decir, a una organización sistemática del trabajo para obtener un 
mayor rendimiento, este objetivo se logrará mediante la evaluación perió. 
dica del sistema. 

La evaluación periódica es una investigación profunda del sistema, 
cuya finalidad es determinar las necesidades actuales del usuario y si el 
sistema cubre las mismas. Esta investigación se debe efectuar como si se 
tratara de un sistema nuevo, y se considerarán los siguientes puntos: 


» Objetivos actuales. Éstos se determinar: 
usuario, según sus necesidades. 

+ Políticas actuales. Las políticas establecidas para un sistema 
pueden variar por diferentes motivos, entre otros, pueden se 
nuevos resultados, nuevos objetivos, recursos materiales, et 
estos factores harán necesario determinar nuevas políticas para 
manejar el sistema. 

+ Entradas. Se investigarán los procedimientos manuales y de capta: 
ción, para determinar si aún son funcionales o deben modificarse o 
cambiarse en su totalidad. 

+ Salidas. En este aspecto básicamente se investigará la funcionalidad 
de los resultados que se obtienen en el sistema. Esto se logra con una 
determinación del objetivo, donde se busca un resultado y la utiliza- 
ción real de éste. 

+ Utilización de resultados. Si al hacer la investigación de la funciona? 
lidad de un resultado obtenido por un sistema se determina que no 
ha sido actualizado en forma adecuada, es necesario hacer notar al 
usuario esta deficiencia en el manejo del sistema, indicándole la 
mejor manera de utilizar el resultado. 

+ Operación del sistema. Este estudio está dirigido al manejo del siste- 
ma; la evaluación de este punto determinará los ajustes que se deban 
hacer, 


en forma conjunta con el 
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+ Rediseño o actualización del sistema evaluado. De la evaluación de 
los puntos detallados anteriormente, se determinará lo siguiente: 


— El sistema cubre las necesidades para las que se creó, y no es nece- 
sario hacerle ningún ajuste. 

— El sistema cubre las necesidades para las que fue creado, pero es 
necesario hacer algún ajuste en algún(os) punto(s) evaluado(s), sin 
llegar a rediseñar el sistema. Si éste es el caso, se deben seguir los 
pasos descritos en el punto de actualizaciones a un sistema. 

— Ya no cubre las necesidades para las que se creó, y por este motivo 
es necesario rediseñar el sistema. Si es así, se deben seguir los 
pasos descritos en esta metodología en lo referente al diseño de un 
sistema. 


ESj 


La improvisación en el desarrollo de sistemas conduce irremediablemente al 
despilfarro computacional. 


186 
RESUMEN DEL CAPÍTULO 17 


Desarrollar un sistema no es tarea sencilla, requiere mucho tiempo de 
estudio y dedicación; representa una gran dosis de investigación y otro tan- 
to de planeación. Implica bastante creatividad por ambos lados: del usuario 
y del analista. Obliga a una labor muy fuerte de análisis de necesidades de 
información, y por tanto, un alto grado de conocimiento del medio para el 
cual se hará el diseño. Esto no se puede adquirir de un día para otro, ni se 
puede improvisar con suposiciones superficiales. Se sabe que muchos siste- 
mas, desde su nacimiento y hasta la fecha, representan sólo altos costos y 
poco aprovechamiento de resultados. Los usuarios no están satisfechos con 
tales sistemas, pues su aprovechamiento es casi nulo, y se dan casos en que 
para obtener un raquítico resultado, se pasan semanas de proceso, que arro- 
jan infinidad de resultados que a nadie sirven, o a los que habrá que hacer 
todavía infinidad de ajustes, surgidos de los datos obtenidos por los proce- 
dimientos manuales del propio usuario. En auditorías practicadas en algu- 
nas instalaciones, se ha encontrado que el 90% de los resultados de un siste- 
ma que consume semanas de proceso son desperdiciados por no interesar a 
nadie, La palabra análisis conduce a un proceso de investigación minucio- 
so. El concepto diseño representa un alto grado de inventiva y creatividad. 
Los pasos del análisis y el diseño obligan a un proceso perfectamente defini- 
do. Significan secuencia, estructura, orden, previsión, precisión, y cual- 
quier ingrediente lógico que ofrezca seguridad y confianza de que se 
cubren las necesidades completas de información para lo que el sistema fue 
concebido. 


18 
La productividad en la 


informática 


Problema 


El aspecto de productividad sigue siendo 
un factor muy pobre en el ámbito computacional 


Alo largo de mi carrera profesional, en el campo de la computación 
electrónica, he tenido la oportunidad de participar en toda índole de pro- 
yectos, desde los más simples hasta los más complejos, calificados así den- 
tro de la esfera tecnológica de nuestro país. Asimismo, he sentido el peso 
de la responsabilidad en la mayoría de los puestos tecnicoadministrativos, 
desde auxiliar de operador de máquinas hasta los niveles gerenciales y de 
liderazgo en las instalaciones más grandes de México. 

Esto me ha hecho reconocer una realidad poco aceptada y muy difusa 
por su naturaleza y alcance, me refiero en concreto al concepto producti- 
vidad, término que por lo general se define como el conjunto de técnicas 
y procedimientos encauzados para obtener el máximo provecho de los 
recursos que tenemos a nuestra disposición, en este caso, recursos de 
cómputo. 

La computadora es sólo una herramienta de trabajo, recurso con el 
cual podemos abreviar la labor de administración y explotación de datos. 
Sin embargo, ¿cuál es el máximo provecho que el hombre puede obtener 
de dicha computadora? La respuesta no es sencilla, pues, honestamente, 
no es posible determinar si la estamos aprovechando con eficiencia; aquí 
surgen otras preguntas: ¿qué significa un uso eficiente?, ¿cuándo resulta 
deficiente), ¿hasta dónde es el alcance hacia arriba y hasta dónde hacia 
abajo», ¿en qué posición nos encontramos? Por lo tanto, ¿producimos o 
no producimos? El hecho de que algunos procesos salgan mediante el 
computador, no necesariamente nos indica que en realidad lo estamos 
aprovechando en forma adecuada, pues podríamos plantear otras pregun- 
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tas: ¿podemos producir más con el mismo computador?, ¿podemos opti- 
mizar los tiempos de los procesos?, ¿realmente requerimos de más gente 
para la obtención de más resultados?, ¿ya se encuentra saturado el compu- 
tador?, ¿está saturado por el mal uso que hacemos de él?, ¿se requiere de 
un computador más poderoso, ¿qué tan poderoso?, etcétera. 

Ya no es necesario plantear otras preguntas, pues sólo nos confundi. 
rían más y no quedaríamos satisfechos, ya que podemos complicarlo tanto 
como queramos. Sin embargo, el problema está ahí, y es tan real que lo 
imos a diario. 

Es frecuente observar una preocupación latente en toda instalación, 
por lo difícil que resulta justificar las altas inversiones de capital que 
requieren estos equipos, además de lo costoso que resulta contar con téc- 
nicos verdaderamente capacitados. Es notorio también palpar un cierto 
grado de competencia de instalación a instalación, por demostrar quién 
ha desarrollado mejores sistemas; e incluso se dice que la instalción más 
grande es la mejor, sin reconocer que en algunos casos es en donde mayo- 
res despilfarros ocurren. 


SUGERENCIAS DE SOLUCIÓN 


1. Aunque este punto podría culminar con cientos de comenta: 
rios, la verdad es que para encontrar la medida que nos ubique dentro 
de un marco productivo se necesita en primera instancia establecer 
que no importa si el centro de cómputo es grande o pequeño, ya que 
siempre existe la posibilidad de hacer las cosas mejor y, de esta mane- 
ra, eliminar o reducir la costumbre de el “ai se va”, pues no existen 
límites para mejorar, y esto sí lo podemos saber; es decir, si cada vez 
mejoramos más, en calidad, orden, satisfactores de información a los 
usuarios, optimización en el uso de recursos de cómputo, capacita- 
ción del personal y cualquier indicio de madurez técnica. 

2. Esobvio que para lograr lo anterior se requieren métodos de trabajo 
perfectamente definidos en cada área, que nos permitan conocer el grado 
de avance. Esta medida es la única que necesitamos, por lo cual es de vital 
importancia que cada área fije sus objetivos concretos, así como los nive- 
les de servicios que persigue, para que así, en ciertos lapsos pueda compa- 
rar si dichos niveles de servicio se están acercando hacia los objetivos 
establecidos de acuerdo con lo planeado. Si no es así, se requerirá hacer 
auditorías técnicas que detecten las razones y establezcan los correctivos 
oportunos para encauzar el camino. De lo contrario, si nuestros objetivos 
se van cubriendo, será sencillo comprender el nivel de productividad y 
mantener los esfuerzos en forma persistente a fin de continuar la trayec- 
toria hacia arriba, sin descuidar ningún factor necesario para mantener 
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dicha trayectoria. De cualquier manera, mediante esta estrategia, tam- 
bién será posible identificar estancamientos o desviaciones, de una mane- 
ra oportuna. 


La productividad sigue siendo un aspecto muy difuso en los centros de 
cómputo. 


RESUMEN DEL CAPÍTULO 18 


Al concepto productividad normalmente se le define como el conjun- 
to de técnicas y procedimientos encauzados a obtener el máximo prove- 
cho de los recursos que tenemos a nuestra disposición; en nuestro caso, 
recursos de computación. Pese a que es un factor vital para contrarrestar 
el fenómeno del “despilfarro computacional”, aún no se ie da la debida 
importancia. Sin embargo, para entender su profundidad y alcance, basta 
con eliminar la costumbre de el “aí se va”. Es obvio que para lograr lo ante- 
rior es necesario apegarnos a métodos de trabajo perfectamente delinea- 
dos para medir nuestro grado de avance. Esta medida es la única que 
necesitamos, por lo cual es vital que cada área fije sus objetivos concretos, 
así como los niveles de servicio que persigue, para que así, en ciertos 
periodos pueda comparar si dichos niveles se están acercando a tales obje- 
tivos; será muy claro entender el nivel de productividad alcanzado. 
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Operación de sistemas 


Problema 


Con frecuencia, los sistemas en 
producción se operan con poco control: esto 
origina reprocesos constantes y demora en la 
entrega de resultados a los usuarios. 


Es importante destacar que la función de operador del computador 
ha cambiado. Tradicionalmente, los operadores del computador opera- 
ban también los sistema en producción. Esta práctica es obsoleta, aun- 
que en instalaciones pequeñas aún se practica. Por el gran auge que ha 
tenido la demanda de uso de equipos de cómputo y la incorporación 
exponencial de nuevos usuarios, las labores de operación han tenido 
que especializarse. En la actualidad, es usual distinguir los siguientes 
tipos de operadores: 


a) Operadores de computador. 
b) Operadores de perifericos magnéticos. 
c) Operadores de impresoras. 

d) Operadores de la red on line. 

e) Operadores de sistemas. 


La función de cada especialidad es muy concreta; los operadores del 
computador se dedican a vigilar mediante los monitores de control (con- 
solas) que el servicio llegue correctamente a todos los usuarios, y a cerrar y 
abrir servicios según los horarios establecidos. También coordinan las 
actividades de otros operadores. 

Los operadores de periféricos magnéticos se encargan básicamente 
del montaje de cintas magnéticas y de habilitación de discos, a fin de man- 
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tener un servicio ágil y rápido en este tipo de labores manuales. 

Los operadores de impresoras tienen a su cargo el montar los distintos 
tipos de papel, y distribuyen con fluidez los reportes impresos hacia las 
distintas unidades usuarias. 

Los operadores de la red on line se dedican a vigilar la disponibilidad 
del servicio remoto hacia las distintas localidades y detectar anomalías en 
las comunicaciones, además de habilitar trayectorias opcionales en caso 
de fallas. Están en estrecha comunicación con todos los usuarios de la red, 
a fin de mantener un nivel eficiente de servicio. Llevan control estricto de 
los horarios de servicio, y cierran o enlazan la comunicación hacia las dis- 
tintas localidades. 

Además, aun cuando los sistemas on line han simplificado el acceso a 
la información mediante terminales de video, como un método ya estable- 
cido, todas las transacciones en tiempo real vuelven a verificarse median- 
te procesos batch, lo cual obliga a trabajar a marcha forzada, a fin de que 
las transacciones de todo un día puedan verificarse una vez cerrado el ser- 
vicio on line, y tener la certeza al siguiente día de que la información dis- 
ponible es sumamente confiable. Por tanto, los operadores de sistemas 
son los encargados de procesar de día y de noche los sistemas batch, y por 
lo general trabajan contra el reloj, ya que cualquier retraso en la produc- 
ción pone en riesgo el servicio puntual del día siguiente. 

Aun así, pese a la gran responsabilidad que tienen los operadores de 
sistemas, existen serias deficiencias de su modo de trabajar. Por lo gene- 
ral, quienes operan los sistemas son verdaderos conocedores de cada pro- 
ceso. Conocen con tal detalle la secuencia de cada corrida, que cuando 
ocurre una falla de inmediato saben qué hacer para activar un reproceso y 
continuar. Son personas que han trabajado varios años con los mismos 
sistemas, y han adquirido tal experiencia que se les considera expertos en 
su manejo, al grado que en casos específicos de falla utilizan trucos inge- 
niosos para dar soluciones. Todo esto es excelente, si no fuera porque 
gran parte de su valioso conocimiento está en su cabeza, y cuando mucho 
se les asigna un ayudante con la intención de que, aunque sea superficial- 
mente, asimile parte de la experiencia. Pero, ¿qué sucede cuando el 
experto se ausenta o renuncia? De inmediato se moviliza al analista, al 
programador, o a cualquier persona que conozca algo de dichos procesos. 
Surge el pánico y, como pueden, aun con demoras en la producción, 
resuelven el problema rogando que se presente el experto. He visto 
casos en que se ha sacado de la cama al experto, inclusive enfermo, 
para que vaya a corregir algún error. He sido testigo de la regularidad 
con que se le cancelan vacaciones por no haber quién se quede en su 
lugar. En muchos casos, se dispone de instructivos dispersos que el 
analista y el jefe de operación tratan de entender para corregir algún 
error en ausencia del experto. 
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Este tipo de situaciones son comunes en la mayoría de los centros de 
cómputo. Los reprocesos se repiten a diario una y otra vez. No importa el 
gasto de recursos técnicos, humanos y financieros; lo importante es lograr 
los resultados. Muchas veces todo vuelve a la normalidad; es decir, a 
depender del experto. Pero así también en bastantes ocasiones la falla no 
se controla con rapidez, y es cuando miles de personas llegan muy tem- 
prano a los bancos, a alguna oficina gubernamental, o simplemente a con- 
firmar un vuelo y encuentran un tumulto de gente desesperada y molesta 
porque sencillamente ¡no hay sistema! 

¿Cuál es el costo en tiempo y dinero de este tipo de situaciones? Práctica- 
mente es incalculable, porque se tendría que preguntar: ¿cuánto vale el tiempo 
de toda esa gente?, ¿cuánto podrían estar produciendo en vez de esperar», 
¿cuántas operaciones comerciales se afectaron?, etc. Ahora bien, ¿cuántas 
veces ha sucedido esto?; no se sabe porque no hay estadísticas. 

Como puede observarse, actividades al parecer sin importancia propi- 
cian situaciones sumamente serias y costosas. Por ello, es impostergable 
asegurar un control estricto en la operación de sistemas, ya que es una 
actividad de alto riesgo en la cual culmina el proceso de datos de un cen- 
tro de cómputo. 


SUGERENCIAS DE SOLUCIÓN 


1. Como primera condición para tratar de solucionar este problema, se 
debe estar consciente que la función de operación de sistemas es vital 
en el entorno del centro de cómputo. 

2. Cuando ya se tiene conciencia de su importancia, es conveniente qui- 
tar dicho control de las manos de un experto. 

3. Es imprescindible elaborar la documentación necesaria y vigilar que 
esté actualizada, de tal manera que personas diestras, pero no exper- 
tas en la operación especifica de los sistemas, puedan operarlos con 
facilidad. 

4. A continuación propongo un método a fin de documentar la operación 
de cada sistema. Es consecuencia de múltiples experiencias y dio resul- 
tados muy satisfactorios. Para esto, me referiré directamente a un caso 

cil que fue resuelto y cuyo método se aplicó también con provecho 

en otras instalaciones: 


Una vez se me pidió que realizara una investigación en el área de con- 
trol de la producción (operación de sistemas), ya que en forma constante 
se retrasaba la entrega de resultados a los usuarios. 

Para empezar, asistí varias noches a examinar cuál era el método con 
que operaban los sistemas. Encontré que no había método, todo el proce- 
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so lo administraba de manera completamente improvisada un experto 
que dominaba a ojos cerrados la mayoría de los sistemas. Los procesos 
principales iniciaban entre las 7 y 9 de la noche y terminaban cerca de las 
6 de la mañana del día siguiente, siempre y cuando se hubicran resuelto 
los problemas que invariablemente ocurrían. Observé que estos proble- 
mas casi siempre tenían relación con las siguientes condiciones: 


a) Errores en la codificación de parámetros de control de los procesos. 

b) Archivos con inconsistencia de datos. 

c) Errores en el orden de secuencia de los procesos; es decir, se olvi- 
daba que era requisito correr tal o cual proceso en esa fecha en par- 
ticular. 

d) No cuadraban las cifras de verificación de algunos procesos debido 
a falta de control de los archivos de movimientos que afectaban a 

los archivos maestros, ya sea que no se introducían los archivos 

correctos o estaban incompletos sus datos. 

Inconsistencias en la codificación de las cláusulas de control 

(CL), porque se codificaban o cuando menos se modificaban dia- 

riamente. 

Cuando ocurría algún error, hasta ese preciso momento se definía 

la estrategia del reproceso por seguir, lo que muchas veces no 

resultaba, y se procedía a buscar otra solución. 


2 


> 


Como se puede apreciar, al iniciar la operación de los sistemas, prácti- 
camente no existía la preparación de todos los elementos de trabajo, por lo 
que durante la noche éstos se preparaban bajo presión. 

Con base en el análisis anterior de la situación, estableci los siguientes 
objetivos: 


a) Documentar el conocimiento de la operación de los sistemas que 
de ellos tenía el experto, Esto se haría de manera prudente, a fin de 
no causar renuencia por parte de aquél. 
La documentación se estructuraría de tal manera que al mismo 
tiempo quedaran asentados todos los parámetros necesarios para 
las corridas, así como todo el conjunto de cláusulas de control 
(JCL) necesarias para todos los casos de procesos y reprocesos. 
c) Una vez que se dispusiera de todos los elementos anteriores, se le 
pediría al experto que aceptara el puesto de supervisor de control 
de la producción, a fin de que los procesos comenzaran a ser opera- 
dos por personas diestras, pero con pocos conocimientos de los sis- 
temas. Ésto permitiría conocer el grado de efectividad alcanzado 
en la documentación. Y sólo intervendría el experto en caso de que 
se presentara un tipo de falla y la estrategia de solución estuviera 


b) 
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mal planteada o no se hubiera considerado. La idea era depender 
cada vez menos del experto 


Con base en el planteamiento de los objetivos anteriores, el proble- 
ma ahora era establecer un formato práctico que permitiera plasmar el 
conocimiento del experto, así como la preparación completa de todos 
los parámetros y cláusulas de control, necesarios para cada caso, tanto de 
proceso como de reproceso, y que además considerara las múltiples 
variantes de acuerdo con corridas especiales de fechas específicas. 
Hacer un manual de tal magnitud no sólo sería tardado sino que se 
correría el riesgo de meterse en un círculo vicioso de correcciones infi- 
nitas, y con el tiempo propiciar que el experto no trasmitiera con clari- 
dad sus conocimientos. 

Hice varios formatos, y finalmente logré uno que resultó ser muy sen- 
cillo y práctico para tales fines, lo denominé “Control matricial de proce- 
sos”. Consistía en un calendario en forma de matriz, uno por cada mes, el 
cual contenía los días del mes, y dentro de cada día los nombres de otras 
matrices, las cuales venían a ser los procesos particulares de cada sistema 
para cada día. En las matrices estaba asentada la secuencia en la cual se 
tenía que iniciar cada proceso y todos los casos posibles de reproceso. 

A continuación, se da un ejemplo del calendario y su relación con 
cada matriz de proceso. 


CALENDARIO DE PROCESOS PARA EL MES afo. 
E. SISTEMAS POR OPERAR 
SECUENCIA > 
Día i 2 3 laa 
1 s E Fu el 


z 


a 


MATRIZ E 
MATRIZ E2 
MATRIZ 5-2 
MATRIZ F 
En osto caso se refiero al mismo sistema S, 
pero con algunas variantes para este dia en 
particular; por lo tanto, habrá una matriz 
especifica llamada $-2. 
MATRIZ s 
Clave dei | Clove del 
Clave doi | paso dentro del | disparador 
Clave del | procedimiento on caso de Condiciones ospocialos 
[Sacuencia| disparador | de JCE deCl | reproceso para reproceso 
1 EN S01P1 SoiPrior | sorpiRor 
SDiPnoz | soiPiRoz 
SDIPHO3 | SDIPIROS | Reprocenar sóio si ol paso 
ELTENO? terminó con cédigo 5. 
En sso contrario ver instructivo 
| S sección SD1PIROS. 
| SDiPnos | sDiPiRos 
sDiPnos | soiPiRos 
2 so2 S02P2 SD2P201 | SD2P2R01 
sD2pao2 | SD2P2R02 
SD2P2103 | sD2P2rea | Reprocesar sóio si toos los 
pasos previos de! procedimiento 
$022 wrminaron con código. 
cero. En naco contrario, var 
insirucivo 5 sección $SD2P2R03. 
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Para aclarar el contenido de la matriz de procesos del día, se tienen las 
siguientes descripciones: 


+ Secuencia. Es el orden en el que se debe activar cada disparador. 

+ Clave del disparador. Es la identificación de un pequeño conjunto 
de cláusulas de control (JCL), que a su vez inician un procedimien- 
to completo. 

+ Clave del procedimiento de JCL Es la identificación de una agrupa- 
ción grande de cláusulas de control (JCL), que cumplen con un 
proceso completo dentro del entorno del sistema. 

+ Clave del paso dentro del procedimiento de CL. Internamente, un 
procedimiento consta de pasos. Cada uno de ellos representa la 
corrida de un programa determinado. 

+ Clave del disparador en caso de reproceso. Es la identificación de 
una agrupación de cláusulas de control (JCL), previamente pre- 
paradas para prever la posibilidad de un reproceso si fallara cual- 
quier paso. 

+ Condiciones especiales de reproceso. Es el comentario acerca de 
una condición de cuidado para el caso de reprocesos. Si no hay 
comentario, el reproceso es normal. 


En sí, esta fue la filosofía determinada para la operación de sistemas. 
La estrategia resultó efectiva, porque dada la sencillez del llenado de las 
matrices, quien lo hizo realmente fue el experto, y lo sintió como creación 
suya, por lo que no hubo resistencia para trasmitir sus conocimientos. La 
codificación de los parámetros y las cláusulas de control fue también 
labor suya, y aunque esto tomó mucho tiempo, resultó relativamente sen- 
cillo gracias a las facilidades de edición en la computadora. Hubo casos en 
que por un solo parámetro de control que variaba se tenían que repetir 
cientos de cláusulas de control, para que así quedara preparada una corri- 
da específica, y no correr el riesgo de hacerlo el mismo día del proceso. La 
consigna era que todo lo que se tuviera que hacer para cualquier caso, ya 
estuviera preparado. 
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La operación de sistemas es una actividad de mucho cuidado, En sí 
representa la culminación de todo el esfuerzo del análisis, diseño y pro- 
gramación de los sistemas de información. Se ha comprobado que no se le 
da la debida importancia, y que ello significa constantes errores y retrasos 
en el servicio de cómputo a los múltiples usuarios. No es admisible que 
por falta de una documentación sencilla y eficiente para el control de la 
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producción se ponga en riesgo la efectividad del centro de cómputo. Por 
eso es impostergable implantar procedimientos estrictos para el control 
de los procesos y documentarlos a fin de no depender de los conocimien- 
tos de un experto. Esta documentación debe ser capaz de lograr que los 
sistemas los operen personas diestras, pero no expertas en los sistemas. La 
consecución de este objetivo quizá tome tiempo, sobre todo por la prepa- 
ración minuciosa a que obliga la codificación de parámetros y las cláusu- 
las de control. Sin embargo, los beneficios lo justifican ampliamente. 
Analice con detenimiento el “Control matricial de procesos” expuesto. 
anteriormente. Estoy seguro de que podrá establecer una estrategia simi- 
lar con los mismos objetivos. 


20 


Usemos las 
microcomputadoras, 
¿pero en qué? 


Problema 


Se les dotó de microcomputadoras a 
los usuarios de las áreas operativas y se 
les abandonó. 


Es evidente que se volvió a dar un gigantesco paso con rumbo a la 
automatización en nuestro país, pero nuevamente sin dirección. A lo 
largo del desarrollo de este libro, se ha hecho hincapié en que en México 
y en la mayoría de los países en vías de desarrollo, se adoptó una tecnolo- 
gía como quien simplemente adopta un niño sin haber pasado por el 
complicado proceso del embarazo y el doloroso parto; es decir, adopta- 
mos la tecnología de la computación electrónica sin haber sufrido el 
laborioso y costoso caminar de la investigación que tuvieron que reco- 
rrer sus descubridores e inventores. Ahora la tenemos a disposición, 
pero nos seguimos resistiendo a pagar el costo de sus beneficios, sin que- 
rer darnos cuenta de que con lo que estamos haciendo perdemos mucho 
más. No terminamos de entender que esta tecnología es complicada y 
requiere de una preparación a conciencia para llegar a dominarla. Que- 
ramos o no, el uso de computadoras todavía en nuestro país resulta ser 
un enfoque novedoso. 

En la década de los sesenta, con la llegada de las primeras computado- 
ras a nuestro país, simplemente las adquirimos como una moda y, en 
nuestra prisa por utilizarlas, no nos dimos el tiempo suficiente para for- 
marnos con una capacitación planeada y adecuada a los problemas que 
deseábamos resolver con estos equipos. Nos desbocamos. Nos precipita- 
mos sin uso de razón. Nos fuimos adentrando a tumbos, tropiezo tras tro- 
piezo. Así creamos nuestra propia "cultura informática”, la cual nos lanzó 
al ojo del huracán de! “despilfarro computacional”. Al paso del tiempo 
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creímos con firmeza que esa debía ser nuestra “realidad informática” y 
nos la adjudicamos, la hicimos verdaderamente nuestra. 

Pese a los esfuerzos de algunos colegas con visión, quienes han trata- 
do de liberarnos del centro mismo del “huracán”, hacia el cual nuestra 
propia ignorancia nos encaminó; por desgracia, como lo comprueba este 
libro, seguimos cautivos víctimas de vicios muy poderosos que por años 
se han arraigado, al grado de que los hemos aceptado como parte misma 
de nuestra deforme “cultura informática”: son “males necesarios” con los 
que hay que aprender a vivir, ¡y vaya que los hemos vivido! 

Pues bien, si aún existiera duda de lo antes dicho, y si en verdad 
hubiéramos madurado ya con suficiente firmeza para emprender un 
camino más productivo y provechoso en el ámbito informático, ¿cómo 
explicar el segundo grande tropiezo que tuvimos con la aparición de las 
microcomputadoras? 

Analicémoslo. A mediados de la década de los ochenta, ya habiendo 
tomado impulso la gran ola que se había venido formando desde los ini- 
cios de esa misma década, nos atropelló frontalmente y nos lanzó hacia la 
“epidemia de las microcomputadoras”. Nuevamente resultó más podero- 
so el impulso de esa gran ola que nuestra frágil preparación, cautivándo- 
nos ingenuamente, y en un par de años inundamos las oficinas de cente- 
nares de empresas con cientos de miles de microcomputadoras. Volvimos 
a engañarnos nosotros mismos, creyendo que estos pequeños artefactos 
trabajan por sí solos y que reclaman una poca o nula preparación por par- 
te de los usuarios. Y así como sucedió en la década delos sesenta, volvimos 
a repetir la misma historia: se lanzaron al mercado cursos al vapor, com- 
pletamente improvisados, con duración de sólo unos días, en los cuales se 
enseñó fugazmente algo del D.O.S., procesador de textos y hoja de cálcu- 
lo. Dado que quienes cursaron dichos temas en su mayoría era personal 
secretarial y de áreas operativas, resultó que académicamente sus estudios 
eran de nivel medio y bajo. Además había que agregar que dicho personal 
no contaba con antecedentes mínimos sobre esta tecnología, resultando 
en que la asimiliación de los conocimientos fue bastante pobre, Aun así se 
les dotó de microcomputadoras y se les abandonó a su suerte, esperando 
que por arte de magia dichos equipos comenzaran a producir. Resultado: 
miles y miles de microcomputadoras inactiv les de usuarios operati- 
vos frustrados; miles de millones de pesos despilfarrados en equipos que 
pronto fueron obsoletos; peor aún, un colosal esfuerzo de recursos huma- 
nos sin provecho importante y la pérdida de una invaluable oportunidad 
de haber tomado control de un fenómeno que nos hubiera permitido de 
una sola vez crear de manera planeada una “cultura informática” a nivel 
de empresa. 

Habiéndonos percatado de esta situación un grupo de colegas y yo, 
lejos de darlo todo por perdido, creímos que el problema ahí estaba, así 
comosus causas. No podíamos desaprovechar esta oportunidad, pues esto 
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nos podría marcar el camino a seguir para superar las deficiencias, Inicia- 
mos una investigación y encontramos lo siguiente. 

Era evidente que la tendencia de las áreas operativas se encaminaba al 
uso de microcomputadoras. Sin embargo, también era notorio que donde 
se habían instalado estos equipos, o bien no se estaban utilizando o se usa- 
ban con un provecho mínimo. Nos percatamos de que muchos usuarios, 
al llegar por la mañana, encendían la microcomputadora, seleccionaban 
el menú más vistoso y así la dejaban el resto del día. Cuando nos acerca- 
mos a preguntarles a varios de ellos por qué hacían eso, su respuesta por lo 
general fue: “No sé que es lo que verdaderamente puedo hacer con este 
equipo que resulte de provecho para el tipo de trabajo que realizo, por eso 
sólo lo enciendo para que se crea que lo estoy utilizando.” Esto nos llevó a 
iniciar una encuesta más profunda a fin de detectar las verdaderas causas 
de esa situación. Encontramos lo siguiente. 


a) Se habían adquirido microcomputadoras, pero no se había capaci- 
a nadie para su utilización. 

b) En algunos casos, se había capacitado a algún personal, pero con 
cursos aislados que no dieron una orientación que les permitiera 
realmente sacar provecho; no fue planeada dicha capacitación, ni 
se establecieron, objetivos específicos para el buen uso del compu- 
tador. 

e) Cuando modestamente se sabía a qué resultados se quería llegar 
con la computadora, se capacitó a algunos mediante cursos al 
vapor, pero no se les enseñó a transportar un problema adminis- 
trativo para ser representado y resuelto mediante técnicas de 
computación. Por esto, el equipo prácticamente permanecía sin 
utilizarse para la obtención de resultados de uso productivo. 

d) Algunos usuarios que fueron mejor capacitados y que pusieron 
empeño en la utilización del computador, de algún modo se 
estancaron, al perderse en un mar de documentos fuente, una 
gran cantidad de archivos que habían creado dentro del computa- 
dor y que ahora les era muy difícil identificar si eran importantes 
o no; se confundieron entre muchos intentos de resultados con lo 
que contaminaban tremendamente el ambiente de discos del 
computador; no sabían cómo respaldar los archivos verdaderos, y 
perdían muchas horas y días de trabajo cuando por error o acci- 
dente los borraban. Prácticamente trabajaban “en el aire” de una 
manera improvisada, ya que no documentaban todos los trabajos 
que iban desarrollando; o sea, no estaban preparados para admi- 
nistrar todos los elementos del computador. Al trabajar de esta 
manera terminaban por abrumarse y abandonaban el uso de este 


equipo. 
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Con base en lo anterior, diseñamos y comprobamos la efectividad de 
un plan de capacitación para secretarias y personal operativo de oficinas, 
al cual le dimos un nivel de diplomado, que aparte de dar un reconoci- 
miento curricular a los asistentes, también representó el haber cursado 
una capacitación seria, efectiva y, sobre todo, completa, con base en obje- 
tivos concretos, no posible de ser adquirida mediante cursos aislados. 

Comprobamos que los módulos con los que estructuramos dicha 
capacitación, bien impartida y con énfasis en la solución de los problemas 
específicos de las áreas en las que laboraban los estudiantes, lograba que 
ellos pudieran resolver la mayoría de los problemas administrativos inne- 
rentes a su área, gerencia o departamento. 

Por lo anterior, queremos poner a disposición del lector el temario 
completo en el cual se basa la capacitación que comprobamos resolvía en 
mayor medida la problemática detectada, así como los argumentos por los 
que cada uno de los módulos fue seleccionado. Por supuesto que esto es 
sólo una sugerencia de solución, misma que el lector podrá evaluar, Lo 
que es un hecho es que a nosotros nos dio muy buenos resultados. 


SUGERENCIAS DE SOLUCIÓN 


Se sabe que gran parte de los problemas administrativos de los 
departamentos y gerencias, sobre todo de grandes empresas, son de vital 
importancia, pero resultan insignificantes vistos por el área de informá- 
tica. De tal manera, que no justifican, aparentemente, el ser atendidos 
con carácter prioritario, por lo cual, pasan meses, incluso años, sin ser 
resueltos, ocasionand> enormes esfuerzos operativos para las áreas que 
los padecen. 

Para aquellas empresas que no cuentan con centro de cómputo, el 
hecho de capacitar a su personal operativo y secretarial les permitirá ir 
reconociendo paulativamente si en verdad requieren de un equipo 
mayor, o si con una o varias microcomputadoras pudieran satisfacer sus 
requerimientos. Pero esto sólo lo sabrán si empiezan a obtener resultados 
efectivos en su microcomputadora, lo que les permitirá detectar si el nivel 
de sus problemas administrativos coincide con el nivel de los resultados 
obtenidos. De cualquier manera, en este momento sí sabran qué tan cerca 
o lejos están de satisfacer sus requerimientos reales. La gran ventaja es que 
no necesitarán una gran inversión para hacerse de este conocimiento. 

El objetivo de esta capacitación a nivel de diplomado, es precisamente 
instruir al personal secretarial y operativo de dichas áreas, con el fin de 
que sin ser expertos en computación, puedan resolver gran parte de sus 
problemas valiéndose de sus propios recursos, sin la necesidad de acudir 
al centro de cómputo de la institución. 
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Mediante la estrategia anterior se alcanzan las siguientes ventajas: 


a) Los departamentos y oficinas podrán resolver muchos de sus pro- 
blemas administrativos de una manera completamente autónoma, 
sin el requerimiento de contratar especialistas en computación. 

b) Los departamentos y oficinas podrán contar con información pro- 
cesada exactamente como la requieren, porque son ellos quienes 

realmente conocen con precisión sus requerimientos. 

Los resultados los podrán tener casi de inmediato, incluso po- 

drán experimentar varias presentaciones, sin pasar por mayores 

trámites. 

d) El computador central no se verá sobrecargado con infinidad de 
pequeños requerimientos. 

e) El área de informática podrá dedicar, con toda su fuerza, tanto 
recursos humanos como materiales, para resolver los proyectos 
altamente prioritarios para la institución, encauzando dicho es- 
fuerzo al desarrollo y operación de sistemas de un elevado nivel de 
servicio, y al proceso de datos de alta calidad. 

f) Elárea de informática no tendrá necesidad de incrementar su per- 
sonal técnico para satisfacer requerimientos no prioritarios, pero 
de alta relevancia para las gerencias y departamentos que los soli- 
citan. 

8) La empresa se verá beneficiada al promover la elevación del nivel 
académico y productivo del personal operativo, el cual en su 
mayoría carece de estudios superiores, y elevará la moral y la cali- 
dad de trabajo de aquellos que obtengan su diplomado. 

h) El personal operativo empezará a ser orientado para interpretar 
las soluciones de los problemas en términos de sistemas de infor- 
mación, lo cual indudablemente redituará en buenos niveles de 
automatización de la institución. 


Es importante destacar que el plan de capacitación informática a 
nivel de diplomado para las áreas operativas tiene como finalidad básica el 
fomentar una “cultura informática” en esos sectores operativos, que a 
mediano plazo sea el inicio de la estrategia de descentralización de la fun- 
ción informática de las empresas, opción que ya es reclamada con urgen- 
cia por la dinámica acelerada con que se están moviendo los modernos 
mecanismos administrativos dentro de las empresas de esta época. La tre- 
menda movilidad que se está dando en los esquemas organizacionales de 
las empresas sugieren que dichas organizaciones están sufriendo vertigi- 
nosamente adaptaciones que tratan de ser congruentes con novedosos 
esquemas administrativos acordes con lo que se ha dado en llamar “la 
empresa moderna”; lo que, en otras palabras, significa que la función 
informática tendrá necesariamente que cambiar; es decir, la informática 
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tradicional ya no cubre los requerimientos que están surgiendo en estas 
nuevas organizaciones que se están formando aceleradamente, 

El concepto de sistematización ya no es posible gestarlo sólo en el área 
de informática. El tipo antiguo de sistemas de información nacientes sólo 
del área de informática, ya no funciona en los nuevos esquemas ni se 
adapta con flexibilidad al ritmo de cambios que están sufriendo en sus 
estructuras las empresas actuales. Ahora se vuelve necesario que la infor- 
mática se dé en cada unidad usuaria, es decir, en el terreno de los hechos. 
Por lo mismo, quřenes deberán tener que sistematizar los mecanismos 
operativos valiéndose del hardware y software idóneos son los propios 
usuarios. Por lo tanto, el concepto de usuario de los siste nas de informa- 
ción también tiene que evolucionar. Ahora serán ellos quienes con sus 
propios medios y con la velocidad requerida automaticen la gran mayoría 
de sus actividades operativas. Esto no es una simple idea; es una necesi- 
dad actual que permitirá agilizar los procedimientos operativos, con 
miras a dar un servicio “de excelencia” hacia los múltiples clientes de las 
empresas. Aquellos que lo consigan, entonces y sólo entonces, estarán 
preparados para competir en los años que se avecinan. 


MÓDULOS DEL DIPLOMADO EN COMPUTACIÓN 


1. PRINCIPIOS DE COMPUTACIÓN Y OPERACIÓN DEL 
SISTEMA D.O.S. 


Este módulo tiene básicamente dos objetivos. Primero, se persigue 
que el alumno aprenda los conceptos básicos del ambiente de micro- 
computadoras, a fin de hacer que entienda que la computadora es un 
equipo sofisticado en su arquitectura, pero dicha complejidad no tiene 
que ver con el hecho de utilizar la computadora. En segundo término se 
le da confianza haciendo que él mismo la maneje mediante ejercicios de 
comunicación con el computador, creándole hasta este momento la certe- 
za de que prácticamente todo lo que está haciendo en dicha comu 
ción resulta sencillo. Esto se logra a través de ejercicios con comandos 
de D.O.S. 

Este módulo se aprovecha para explicar al estudiante el concepto de 
sistema, y para lograr que aprenda con claridad la manera como se identi- 
fica un problema administrativo que amerite ser automatizado, y los pasos 
ordenados que habrá que dar para transportarlo al computador para su 
resolución. 


Temario del módulo 1 


+ Terminología utilizada en computación. 
+ Características de los componentes de una microcomputadora personal. 


204 CAP. 28. USEMOS LAS MICROCOMPUTADORAS 


+ Conceptos del sistema operativo D.O.S. 
» Uso de comandos indicadores de D.O.S. 
» Descripción de la estructura de directorios. 

Uso de comandos para crear, organizar, imprimir y depurar directorios. 
Uso de comandos para copiar, imprimir, mover y depurar ambientes de 
archivos en discos. 

Uso de comandos auxiliares del D.O.S. 

Método para Respaldo y recuperación de archivos. 

Estructuración y ejecución de grupos de comandos. 

Método para crear un ambiente de disco duro bajo el sistema D.O.S. 
Identificación de problemas y pasos a seguir para resolverlos en el 
computador. 

Laboratorios de todos los puntos anteriores. 

Evaluación final del asistente. 


Duración del módulo 1: 40 horas. 


II. OPERACIÓN DE LA HOJA DE CÁLCULO (LOTUS u otro 
paquete) 


Con base en el módulo anterior, en este momento el alumno ya expe- 
rimentó la comunicación con el computador y ya cuenta con la certifica- 
ción de que ha entendido los conceptos básicos, pues así está diseñado el 
módulo; es decir, no se permite pasar a un siguiente tópico hasta no haber 
logrado los objetivos previos. Las evaluaciones certificadas por los resulta- 
dos obtenidos en el propio computador nos dan esta garantía. 

En este segundo módulo se le capacita al alumno primeramente en la 
operación del programa LOTUS, a fin de que pueda crear archivos par- 
tiendo de la estructura de hojas de cálculo. Asimismo, se le enseña a pro- 
cesar dichos archivos y a obtener resultados objetivos. Una vez logrado el 
manejo de LOTUS mediante la estrategia anterior, ahora se procede a 
definir el planteamiento de un problema teórico pero muy fácil de enten- 
der, a fin de ir aplicando la metodología para lograr transportarlo al 
computador y finalmente obtener los resultados planeados. En este punto 
el alumno adquiere la capacidad, y además se convence de que lo que está 
haciendo requiere mucha atención, pero es como si estuviera aprendien- 
do cualquier otra materia académica. La ventaja es que aquí lo está 
haciendo él mismo y está comprobando inmediatamente el resultado de 
sus acciones. Para afianzar los conceptos se hacen varias prácticas con dis- 
tintos planteamientos. Lo importante es comprobar que aún sin el domi- 
nio de algún lenguaje de programación es factible automatizar en gran 
medida una oficina o departamento. 


USEMOS LAS MICROCOMPUTADORAS 205 


Temario del módulo II 


+ Procedimiento para instalar el programa LOTUS. 

+ Como entrar y salir de LOTUS y como accesar una hoja de cálculo. 

+ Características de las hojas de cálculo. 

+ Operación para el movimiento del cursor y manejo de páginas en la 
pantalla. 

+ Manejo y selección de menús de comandos. 

+ Creación y borrado de las hojas de cálculo. 

+ Captura de datos y Fórmulas de proceso. 

+ Manejo de comandos para estructurar celdas. 

+ Manejo de comandos para copiar y mover celdas. 

» Uso de comandos para insertar y borrar columnas y renglones de las 
hojas de cálculo. 

© Comandos para imprimir las hojas de cálculo. 

+ Uso de teclas de funciones especiales. 

. Definición de problemas y solución mediante el esquema de hojas de 
cálculo. 

+ Evaluación final del asistente. 


Duración del módulo ll: 60 horas. 


II. OPERACIÓN DEL PROCESADOR DE TEXTOS (WordStar u 
otro paquete) 


Este módulo tiene un objetivo concreto. Dicho objetivo es adaptar al 
alumno al concepto de archivo magnético. Es evidente que el personal de 
oficina lo que más conoce y a practicado por años, es que el elemento 
de papel escrito es sin duda el objeto de mayor uso en dichos lugares, a tal 
grado que con frecuencia se tiran toneladas cuando rebasan la capacidad 
de almacenamiento; por supuesto, no sin antes dedicar días y semanas a 
una depuración. Aun con mucho cuidado, el extravío de documentos 
importantes es mayor al que se pueda uno imaginar. Por otro lado, el 
esfuerzo para archivarlos y mantenerlos en orden para un fácil acceso es 
tan alto que muchas veces es la actividad que mayor tiempo le toma a los 
oficimistas. 

El concepto de archivo magnético suprime de inmediato muchas acti- 
vidades tradicionales y simplifica muchas otras, y ahorra además espacio 
físico dedicado al archivo y, por supuesto, reduce enormemente los ries- 
gos de extravíos. 

Durante este módulo se le instruye al estudiante para utilizar el pro- 
cesador de palabras WordStar, a fin de lograr mayor velocidad en la meca- 
nografía, correcciones mecanográficas instantáneas, eliminación del des- 
perdicio de papel, y organización y consulta instantáneas del archivo. Se 
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le capacita también para obtener escritos con presentaciones agradables a 
la vista y de muy alta calidad, al combinar distintos tipos de letras. Final- 
mente, se le enseña al alumno a combinar el procesador de palabras con 
archivos de datos, a fin de hacer comunicados masivos, personalizando 
cada carta con los datos de clientes, proveedores, destinatarios adminis- 
trativos, etcétera. 


Temario del módulo HI 


+ Procedimiento para instalar el programa WordStar. 

+ Cómo entrar y salir de WordStar y cómo crear documentos. 

+ Procedimiento para capturar textos. 

+ Operación para el movimiento del cursor y manejo de páginas en la 
pantalla. 

+ Uso de comandos para borrar textos. 

+ Uso de comandos para mover textos. 

+ Uso de comandos para copiar textos. 

+ Uso de comandos para insertar textos. 

+ Uso de comandos para grabar los textos en disco. 

+ Uso de comandos para búsqueda y sustitución de textos. 

+ Uso de comandos para imprimir textos. 

+ Uso de comandos para definir un formato al documento. 

+ Uso de comandos especiales. 

+ Combinación de documentos y datos variables. 

+ Planteamiento de problemas y laboratorio. 

+ Evaluación final del asistente. 


Duración del módulo IlI: 40 horas 


IV. OPERACIÓN DE UTILERÍA DE ESCRITORIO (SideKick u 
otro paquete) 


Con el uso de estos programas de utilería se capacitará al asistente 
para: organizar, actualizar, consultar e imprimir agendas de citas, directo- 
rios telefónicos, bibliografía, documentos de oficina, control de activida- 
des de empleados, control de asistencias, uso de calculadosa, control de 
gastos, y en general actividades muy rutinarias. bjetivo es simplificar 
el esfuerzo y tiempo para llevarlas a cabo. 


Temario del módulo IV 


+ Procedimiento para instalar el programe SideKick. 
+ Características generales y modo de ejecución del programa SideKick. 
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Manejo de Ventanas (Windows). 
Operación de la calculadora. 

Operación del calendario y la agenda. 
Operación del cuaderno de notas y recados. 
Operación del directorio telefónico. 
Planteamiento de problemas y laboratorio. 
Evaluación final del asistente. 


Duración del módulo IV: 40 horas. 


V. ADMINISTRACIÓN DE UN AMBIENTE AUTOMATIZADO EN 
COMPUTADOR 


En este módulo se enseñan al alumno las técnicas necesarias para 
lograr la administración de un ambiente automatizado, de tal manera 
que obtenga el máximo provecho de la puesta en práctica de lo apren- 
dido en los módulos anteriores; se le prepara así para: documentar los 
trabajos hechos en el computador, depurar y mantener un ambiente 
confiable de archivos generados en sus dispositivos de disco, recuperar 
datos perdidos por daños físicos de su computador o por errores come- 
tidos, formación de nomenclaturas de identificación requeridas en 
lades de computación, diseño de formatos de apoyo para facilitar 
la automatización, y en general los tópicos que le enseñen la disciplina 
necesaria para el buen uso de los recursos de cómputo. 


Temario del módulo V 


+ Metodología para la administración de los elementos que intervienen 
en la automatización de los sistemas de información. 

+ Nomenclatura de control para la automatización. 

+ Técnicas de seguridad de datos. 

+ Estrategias de respaldo y recuperación de archivos. 

+ Metodología en el desarrollo de sistemas de información 

+ Técnicas de documentación. 

+ Aplicación de los conceptos anteriores a un problema real basado en las 
necesidades de información de la oficina en la que trabaja el propio asis- 
tente. 


Duración del módulo V: 40 horas 


En conjunto, los cinco módulo: permiten al personal secretarial y 
operativo de oficina hacer un uso efectivo de la microcomputadora, para 
sistematizar gran parte de las operaciones administrativas de un departa- 
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mento o gerencia. Debe apreciarse que cada módulo de capacitación se 
entrelaza con los otros; es decir, es una capacitación integral que hace que 
se aprecie como un todo y no como simples cursos aislados. 


Una vez terminada la capacitación, debera asignarse un coordi- 
nador cuyo propósito sea hacer un seguimiento efectivo a fin de 
comprobar que quien ya es diplomado en computación verdadera- 
mente emprenda la puesta en práctica de sus conocimientos, y aquél 
lo asesorará para que inicie un análisis de requerimientos de su pro- 
pia oficina o departamento. Así mismo, el coordinador deberá hacer 
visitas periódicas con el objeto de comprobar la eficiencia del uso del 
computador por parte del diplomado y, en su defecto, analizar las 
causas de una baja productividad, y tomar medidas correctivas. El 
objetivo es no permitir que se desperdicie lo aprendido, sino que por 
el contrario, se amplíe el buen uso del computador. Fomentar la dis- 
ciplina en el buen uso de los recursos de cómputo por parte de los 
usuarios operativos, en gran medida también le de la motiva- 
ción que generen los jefes o gerentes de los distintos departamentos 
y, por supuesto, de la creatividad de ellos para hacer que el compu- 
tador sea utilizado en la solución de lòs verdaderos problemas de 

la área, 
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La “moda” de las microcomputadoras nos tomó por sorpresa y, dado 
que no aprendimos de nuestra triste experiencia en la década de los sesen- 
ta con las primeras computadoras, ahora volvemos a repetir la historia, 
precipitándonos a inundar las oficinas con estos equipos, creyendo que 
con una capacitación superficial y no planeada, los usuarios de nivel ope- 
rativo podrán sacarles realmente provecho. Los resultados de (no pode- 
mos decir “de esta estrategia”, porque no la hubo) esta experiencia nueva- 
mente se coronaron con un enorme despilfarro en todos los sentidos. Sin 
embargo, aquellos que de alguna manera quisimos participar en rescatar 
algo de lo mucho desperdiciado, exploramos un plan de capacitación 
integral a nivel de diplomado, el cual por los resultados satisfactorios 
obtenidos, ponemos a disposición en este capítulo. 
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Insistimos en que el temario aquí expuesto es sólo una sugerencia, 
y puede ser complementado o afinado. Sin embargo, la experiencia nos 
demostró que bien llevado a la práctica, el objetivo se cumple cabal- 
mente. 

Debe enfatizarse que el elemento más importante de este plan de 
capacitación es el seguimiento posterior, a fin de supervisar la correcta 
aplicación de los conocimientos, directamente en las labores diarias de 
quienes recibieron el diplomado. Sin este elemento de seguimiento, com- 
probamos que los estudiantes no llegan, en su mayoría, a ser productivos 
en el uso del computador, y un alto porcentaje termina por dejarlo en el 
olvido. 


21 


Funciones y 
responsabilidades del 
área informática 


Problema 


Muchos de los integrantes del área de 
informática trabajan por órdenes de trabajo 
según se van presentando y no por 
conocimiento de sus funciones y 
responsablidades que enmarquen los 
objetivos concretos que los ubiquen. 
claramente dentro de la organización. 


Cuando en un centro de cómputo no existe la definición precisa de 
funciones y responsabilidades, es muy difícil distinguir los límites de tra- 
bajo que deberá cubrir cada área. Esto origina una tendencia muy alta a la 
asignación empírica de las actividades a ser desarrolladas para la culmina- 
ción de cada proyecto; y en consecuencia, a delegar la mayoría de las ac 
vidades en los técnicos más capacitados, convirtiéndolos así en “todólo- 
gos"; es decir, aunque determinadas actividades no recaigan dentro del 
marco de responsabilidad de éstos, por su capacidad técnica, las absorben 
tan sólo porque les fueron asignadas, aunque esto desequilibre las cargas 
de trabajo, ya que mientras a ellos se les satura, otros técnicos permanecen 
inactivos. 

Otro problema resulta cuando algún técnico es controlado y empieza 
a recibir asignación de trabajos a diestra y siniestra y sin una orientación 
específica de un puesto claramente defínido. Esto lo desorienta y no logra 
distinguir cuáles son sus funciones y responsabilidades, y cuáles sus lími- 
tes de acción. Simplemente, lo absorbe la desorganización de la instala- 
ción y al poco tiempo es un “todólogo” más, inmerso en la terrible confu- 
sión que impera. 

Este esquema elimina prácticamente la posibilidad de estructurar 
planes de capacitación por objetivos, ya que en cierto momento todos 
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hacen de todo, y nunca sabrán cuál será su avance dentro de esa desorga- 
nización. 

El peligro a que conduce esta situación, salta a la vista para aquellos que 
lo observan desde afuera. Sin embargo, adentro todo es tan confuso que se 
dejan llevar simplemente por la inercia del terrible descontrol, hasta que tar- 
de o temprano el centro de cómputo no soporta más y se empieza a desinte- 
grar. Esto lo detectan cuando comienzan las inconformidades personales; las 
renuncias en masa; el incumplimiento de los satisfactores de información 
hacia los usuarios; los problemas frecuentes de falla de procesos en produc- 
ción, los cuales día con día se acumulan; la impotencia para organizar en 
situaciones de crisis; etc. En ese momento nadie se siente responsable de lo 
que está sucediendo, sino hasta que alguien decide afrontar el problema y 
establece, como única medida sensata, que la solución es estructurar cada 
área de acuerdo con responsabilidades y funciones que permitan distinguir 
claramente quién, cuándo y hasta dónde deberán cubrir cada fase de un pro- 
yecto dado. 


SUGERENCIAS DE SOLUCIÓN 


En estos caso no es tan difícil proponer una solución, lo difícil es 
estructurar el esquema funcional de la organización a través de un plan- 
teamiento integral en el cual se vislumbren las distintas áreas que deben 
conformarla: la descripción de cada puesto, la descripción de su responsa- 
bilidad concreta y la definición de actividades de detalle que deberán 
cubrir para lograr la correcta consecución de los objetivos por los que 
cada puesto fue concebido. 
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Cuando en un centro de cómputo no existe la definición precisa de 
las funciones y responsabilidades de cada área, se origina una tendencia 
muy alta para la asignación empírica del trabajo. Así nacen los “todólo- 
gos”, quienes sólo destapan un hoyo para tapar otro, sin concretar ningún 
trabajo. Asimismo, cuando un técnico nuevo es contratado, se le empieza 
a asignar trabajo a diestra y siniestra y sin orientación específica. Esto lo 
desorienta y es absorbido por la terrible desorganización de la instalación, 
así nace otro “todólogo”. Este esquema elimina prácticamente la posibili- 
dad de estructurar planes de capacitación por objetivos. Será necesario 
que los jefes de la instalación instrumenten un organigrama funcional 
donde se pueda justificar cada puesto con base en las funciones y respon- 
sabilidades que deberá cubrir. 
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En busca de la 
excelencia en la 
función informática 


Problema 


No existe excelencia en la función infor- 
mática. 


Antes de entrar en materia, debo aclarar que voy a reiterar parte de la 
información que ya ofrecí en el primer capítulo, Esto es necesario, ya que 
a esta altura es probable que el lector haya olvidado algunos detalles de 
importancia. En èste capítulo se concentran los conceptos más sobresa- 
lientes del libro, por lo que se recomienda especial atención. 

Como se habrá percatado el lector, los temas tratados en el presente 
trabajo reflejan una realidad expuesta con frialdad, que incluso pudo 
haber llegado a incomodar a aquellos que de alguna manera se identifica- 
ron como partícipes de alguno o varios problemas aquí descritos. Pero 
como fue señalado al principio del libro, no se trata de ver hacia atrás con 
el propósito de encontrar culpables; por el contrario, los errores vist 
como experiencias son los resortes impulsores que permiten encontrar la 
soluciones; y sobre todo, ofrecen la valiosa oportunidad de participar en la 
consecución de dichas soluciones; y en el trayecto que incluso puede 
resultar agotador, poner a prueba nuestra capacidad profesional y benefi- 
ciar tanto a uestros centros de trabajo como a nosotros mismos con ese 
nuevo cúmulo de experiencias que encontraremos en el camino. 

Por otro lado, confío en que los estudiantes hayan comprendido, a 
costa de nuestras deficiencias técnicas, la enorme cantidad de trabajo que 
falta por hacer, y adviertan que les espera un amplio campo de acción, 
que visto otra vez como oportunidad, representa un trayecto sumamente 
apasionante, el cual, sí se descubre con esfuerzo, tesón y constancia, el 
futuro de la informática en nuestro país será más promisorio. 

Al titular este último capítulo del libro “En busca de la excelencia en 
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la función informática” deseo destacar la enorme importancia que repre- 
senta esta tecnología como acelerador del desarrollo de un país. 

Si se parte de la base de que los países en vías de desarrollo heredaron 
dicha tecnología, adquirida sin haber pasado por el laborioso y costoso proce- 
so de investigación que hubieron de realizar sus descubridores, no es admisi- 
ble que se desperdicien sus bondades al hacer un uso deficiente, muchas 
veces tendiente al despilfarro. Por eso es importante reconocer que la fun- 
ción administrativa en los centros de cómputo podrá servir de indicador para 
detectar el nivel de eficiencia del uso de los recursos de cómputo o en su 
defecto el grado de desaprovechamiento y, peor aún, el grado de despilfarro. 

En busca de la excelencia en la función informática quiere decir: enten- 
der esta tecnología; reconocer su importancia como impulsora de las demás 
tecnologias, y sobre todo, obtener el máximo provecho al aplicarla. También 
significa: aceptar que es una tecnología nueva en nuestro país, cuya difusión 
ha sido lenta, sobre todo en el ámbito educativo; reconocer que no estamos 
preparados académicamente para el nivel que reclama su complejidad; com- 
prender que no se le ha dado la importancia que merece. Pero ante todo 
indica que nos hemos dado cuenta de que sin esta tecnología ningún país 
saldrá del subdesarrollo; que estamos dispuestos a reconocer su importan- 
ciaya promover su comprensión en las escuelas; que estamos dispuestos a 
pagar el precio de sus beneficios, aceptando que su utilización requiere de 
un alto grado de especialización y no puede tolerarse la improvisación al 
respecto. 

Para la década de los noventa muchos países, entre ellos México, 
han emprendido su modernización. Su objetivo es entrar al año 2000 
con un nivel tal de competitividad que permita subir peldaños de pros: 
peridad y acercarse lo más posible al bloque de los países más desarro- 
lados. No hacerlo significaría no sólo rezagarse, aumentando así la 
distancia tecnológica entre unos y otros, sino que sería tremendamen- 
te peligroso para la humanidad la existencia de más países consumido- 
res que productores. 

Parte de la estrategia de modernización consiste en abrir las eco- 
nomías, de tal forma que otros países inviertan grandes capitales en 
industrias y en un sinnúmero de empresas, a fin de incrementar la 
producción, aumentar las fuentes de trabajo, promover el comercio 
internacional, reactivar la economía, etcétera. 

Visto desde otra perspectiva, si existen más industrias, comercios, 
transacciones económicas, producción, empleos y dinero, habrá mucho 
más intercambio y control de información. ¿Qué se deduce de esto?; sen- 
cillamente que el uso de las computadoras se incrementará considerable- 
mente. Y, ¿qué importancia tiene lo anterior? significa una gran respon- 
sabilidad para los informáticos del país, ya que los recursos tecnológicos 
para proceso de datos que habrán de introducir los inversionistas extran- 
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jeros serán los más modernos y complejos de la actualidad. Por principio, 
nos deberíamos preguntar si existen suficientes técnicos y profesionales 
en informática para estos nuevos centros de computo. Segundo, ¿nuestro 
nivel tecnológico nos permitirá rápidamente ser diestros en el uso de esos 
nuevos equipos? Tercero, si no es así ¿nos estamos preparando para ese 
momento? Sinceramente no tengo la respuesta. En lo que sí puedo cola- 
borar es en dar a conocer los últimos resultados de mi investigación sobre 
administración de centros de cómputo, a fin de recomendar mis expe- 
riencias para reducir el “despilfarro computacional”, y en la medida de las 
acciones a tomar, lograr un mayor nivel de excelencia en la función infor- 
mática, al realizar un uso más eficiente de los recursos de cómputo que 
tenemos a nuestra disposición actualmente. Mi propósito es que cuando 
esté en auge la modernización del país, hayamos alcanzado un mayor gra- 
do de madurez en materia de cómputo, y estemos ya en mejores posibili- 
dades de ser eficientes en el uso de la nueva tecnología que llegue. 


ÚLTIMOS RESULTADOS DE MI INVESTIGACIÓN 
SOBRE ADMINISTRACIÓN DE CENTROS 
DE CÓMPUTO 


Antes de comenzar con la descripción de estos resultados, quiero 
mencionar que en octubre de 1989 tuve la oportunidad de ofrecer una 
conferencia en el evento internacional Compuntundo 89, celebrado en el 
salón de la informática del hotel María Isabel Sheraton de la ciudad de 
México. Allí expuse los resultados de mis investigaciones entre conocidos 
especialistas en informática y directivos de los centro de cómputo más 
grandes del país. Los comentarios con los que fui retroalimentado certifi- 
can la veracidad de mi exposición, porque no sólo conseguí el acuerdo 
unánime, sino la disponibilidad para poner en práctica mis recomenda- 
ciones, 

Meses después comencé a tener las primeras noticias sobre la puesta 
en marcha de la estrategía recomendada en mi estudio, y los resultados 
han sido considerablemente eficaces, y sobre todo positivos casi de inme- 
diato. Por eso estimo útil hacerlo extensivo a los lectores, con el firme pro- 
pósito de aportación. 


DESARROLLO DEL ESTUDIO 


El objetivo es demostrar que la falta de la función administrativa 
global en los centros de cómputo es la razón básica de los errores que 
en él se cometen 
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Para lo anterior, se partirá de la siguiente proposición: 
Los centros de cómputo no están administrados. 


Parecería que la anterior es una aseveración demasiado aventurada; 
sin embargo, fue la conclusión rotunda que arrojó el estu 

Empezaré por señalar algunos puntos sumamente importantes sobre 
la representatividad que han alcanzado los centros de cómputo dentro de 
las instituciones: 


a) En sí un centro de cómputo representa una entidad dentro de la 
empresa, la cual tiene como objetivo satisfacer los requerimientos 
de información de la misma. 

b) Su función primordial es apoyar con eficiencia la labor adminis- 
trativa de la empresa, para hacerla más segura, fluida y simplifica- 
da. 

e) En el centro de cómputo recae la responsabilidad de la centraliza- 
ción, custodia y proceso de la mayoría de los datos con los que 
opera la empresa. 

d) Prácticamente la mayoría de las actividades del resto de las áreas 
dela organización toman como base la información que les provee 
dicho centro. 

e) La toma de decisiones en los distintos niveles se ve influenciada 
por la calidad que posea la información y por la capacidad de res- 
puesta del procesamiento de datos. 

f) En gran medida, la eficiencia del centro de cómputo representa el 
nivel de sistematización alcanzado por la empresa, 

g) La importancia que adquiere el centro de cómputo dentro de la 
organización lo compromete fuertemente en las decisiones admi- 
nistrativas y de proyección de la empresa. 


Si se observa ton cuidado lo anterior, llegamos a la siguiente con- 
clusión: 


El centro de cómputo es uno de los engranes vitales dentro de la 
organización, el cual hace que muchos otros se detengan o caminen sis- 
temáticamente. 


Si en este momento evaluamos la afirmación: “Los centros de cómpu- 
to no están administrados”, las consecuencias en el sentido de “Esto es la 
razón básica de los errores que en él se cometen” y lo confrontamos con 
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“La importancia del centro de cómputo dentro de la organización”, resul- 
ta estremecedor imaginar el altísimo costo y las graves repercusiones de 
dicha situación. 

Ahora hagamos un análisis de: ¿cómo fue identificado el problema), y 
¿por qué se llegó a tal afirmación? 

Esto surgió como resultado de una profunda investigación que me 
fue solicitada por el director de uno de los centros de cómputo más gran. 
des del país. Allí encontré lo siguiente: 


1. Evaluación de los compromisos de trabajo. 


a) La mayoría de los jefes del centro de cómputo se comprometían a 
entregar resultados en tiempos récord, y muy Frecuentemente no 
consideraban la opinión de los que realmente lo harían, simple- 
mente lo exigían sobreponiendo su autoridad. 

b) En otros casos, resultaba que dichos jefes prácticamente no tenían 
otra opción más que aceptar los tiempos marcados por los directi- 
vos de mayor nivel de la organización. Se detectó que esto se deri- 
vaba del distanciamiento y poco conocimiento que sobre las labo. 
res del centro de cómputo tenían dichos directivos. 


2. Equilibrio de las cargas de trabajo. 


a) Con frecuencia habia saturación de trabajo por falta de controles 
efectivos, razón por la cual prácticamente no existía labor de 
investigación orientada al mejor aprovechamiento de los recursos 
de cómputo, pese a que era evidente una utilización deficiente, 

b) En forma contradictoria, mientras ciertas áreas estaban saturadas, 
Otras permanecían ina 


3. Evaluación del hardware y el software. 


a) Se detectó que se había adquirido mucho software, su utilización 
era escasa y varios productos prácticamente no eran utilizados; es 
más, la mayoría de los técnicos desconocían que existieran. La sor- 
presa fue mayor cuando se encontró que aún se pagaba renta de 
algunos que nunca se utilizaban. 

b) Al no haber mediciones o no ser reales, en cuanto a la creciente 
saturación de hardware, con frecuencia se precipitaba su adquisi. 
ción cuando comenzaban los cuellos de botella en la producción 
y/o los tiempos de respuesta de los sistemas on line se tornaban 
críticos, 
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4. Los métodos de trabajo. 


a) Se encontró que eran muy superficiales y carecían de una 
correcta documentación, razón por la cual no existía un están- 
dar en el desarrollo de los trabajos, obligando muchas veces a la 
improvisación. 

b) Debe decirse que en algunas áreas se encontraron manuales de con- 
trol perfectamente documentados, pero algunos no se respetaban. 


5. Control de cambios. 


a) Pese a la importancia de este punto, frecuentemente cuando por 
fallas de programas se obligaban correcciones, o cuando por la 
dinámica de los sistemas se requería de cambios, la mayoría era 
realizada en forma apresurada mediante reparaciones improvisa- 
das, bajo controles superficiales o simplemente sin control. 

b) Lo anterior ocasionaba reprocesos por nuevas fallas o resultados 
incorrectos, muchos de ellos detectados cuando el usuario recibía 
la información de los procesos. 


6. Elaboración de programas. 


a) Cuando se analizaron los reportes estadísticos sobre la cantidad 
de veces que se requería compilar y probar los programas en desa- 
rrollo, nunca imaginamos lo que ibamos a encontrar. El promedio 
de compilaciones para depurar un programa nuevo consistía en 
50 entradas al computador. Por si fuera poco, las entradas que se 
efectuaban durante la etapa de pruebas, hasta lograr los resultados 
correctos, superaban las 85. 

b) Entonces comprendimos por qué había una computadora de 
capacidad considerable, exclusiva para el desarrollo de sistemas. 


7. Operación de sistemas. 


a) Respecto a la operación de los sistemas en producción, se detec- 
tó que la preparación de los elementos necesarios para los proce- 
sos en batch se realizaba generalmente hasta el momento de las 
corridas, lo cual al hacerse en forma precipitada generaba cons- 
tantes errores. 

b) Las personas que tenían a su cargo esa labor eran técnicos de bajo 
nivel en la mayoría de los casos, lo cual resultaba insólito, sobre 
todo cuando precisamente la culminación del tremendo esfuerzo 
del análisis de sistemas, programación y puesta en marcha de 
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dichos sistemas se da en el momento de la producción real de los 
procesos. Por esto, no es admisible que por la poca preparación de 
estas personas se vea altamente deteriorada la eficiencia de esos 
sistemas. 


e) Se encontró que además no era adecuada la calidad de los instruc- 
tivos para la operación de los sistemas, cuando éstos existían; por- 
que había varios sistemas que carecían de ellos. 


8. Análisis y diseño de sistemas. 


a) A este respecto, era evidente que no se seguía un método 
estándar bajo el cual se pudiera garantizar que todos los siste- 
mas,sin excepción, serían administrados durante su desarro- 
llo y su puesta en operación. 

b) Durante las pláticas con algunos usuarios, hubo comentarios res- 
pecto a que varios sistemas les fueron impuestos, y que en la prác- 
tica los resultados de éstos no satisfacían plenamente los requeri- 
mientos de información; de esta manera, varios resultados jamás 
eran utilizados. 

c) Se identificó la gravedad de que varios sistemas partían de proble- 
mas supuestos en donde no se había hecho un análisis profundo, 
por lo que con el tiempo originaban ajustes frecuentes, debido a la 
poca previsión que se tuvo. 

d) Se encontró que en no pocos casos se desarrollaban sistemas para 
áreas que no estaban todavía administrativamente estabilizadas. 
Dicho requisito por supuesto que cuestionó la seguridad de estos 
sistemas. 


9. Administración de archivos. 


a) La nomenclatura utilizada para identificar cada archivo no estaba 
sujeta a estándares. 

b) Lo anterior originaba la saturación injustificada, principalmente 
en los paquetes de disco. 

c) Dicho desorden complicaba terriblemente la depuración sistemá- 
tica de archivos; entonces tenía que realizarse en forma manual, 
con la consiguiente incertidumbre y riesgo constante de pérdida 
de información valiosa, lo cual ya había ocurrido en no pocos 
casos. 

d) Otro problema generado por tal situación consistía en las equivo- 
caciones frecuentes, ya fuera al correr programas de versiones 
obsoletas al hacer procesos con archivos no actualizados, paráme- 
tros erróneos, etcétera, 
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e) En ese ambiente de confusión era evidente que la confidencialidad, 
integridad y seguridad de los datos resultaba prácticamente nula. 


10. Administración del sistema operativo. 


a) Se descubrió que se llegaban a instalar sistemas operativos no 
depurados, los cuales tenían muchos errores de diseño, para los 
que generalmente ya existían las correcciones; sin embargo, no se 
realizaba en forma anticipada la investigación correspondiente. 

b) Cuando atinadamente se descubrían algunos errores del sistema 
operativo y se aplicaban las correcciones necesarias, éstas no eran 
probadas en forma rigurosa; y como es sabido, algunas correccio- 
nes originan otros errores, 

c) Cuando se decidía migrar de una versión a otra, ya fuera por 
demasiados errores en la anterior o facilidades útiles en la nueva, 
generalmente no pasaba por un examen de pruebas masivas; por 
lo tanto, en la nueva versión ocurrían fallas que en la anterior no 
habían sucedido. Por supuesto que esto llegaba a crear descontrol 
y pérdidas cuantiosas en los procesos. 

d) En muchas ocasiones permanecían los mismos parámetros de control, 
de la versión de un sistema operativo anterior, sólo para desperdiciar 
las nuevas facilidades con que contaba el más reciente. También suce- 
día que se dejaban los parámetros de la nueva versión tal y como era 
recibida del distribuidor y tiempo después se detectaba que éstos no 
eran congruentes con las características particulares de la configura- 
ción de equipo con que contaban. Para entonces; ya habían surgido 
problemas. 


11, Las bases de datos. 


a) En la instalación donde se realizó la investigación se acudió al his- 
torial a fin de conocer qué proceso se utilizó en la migración a las 
bases de datos. Se encontró que no había ningún estudio que esta- 
bleciera el plan bajo el cual se trabajó. Se concluyó así que no se 
había hecho conciencia de sus implicaciones. 

b) Se detectó que efectivamente ya estaban trabajando en un 
ambiente de base de datos, pero que su explotación era muy defi- 
ciente. Las razones para esta afirmación se fundaron en las 

iguientes observaciones: 


+ Era una base de datos “forzada”; es decir que simplemente 
habían convertido sus archivos tradicionales al nuevo ambiente, 
acarreando mucha de la redundancia de datos que ya existía. 
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e Por lo anterior, los nuevos sistemas prácticamente seguían siendo 
independientes, con el consiguiente desperdicio del enorme 
potencial quelas bases de datos ofrecen en los sistemas integrales. 


INFORME PRELIMINAR DE LA INVESTIGACIÓN 


Con todos los datos anteriores se realizó un documento, en calidad de 
informe preliminar, el cual fue presentado en una junta donde acudieron 
las distintas áreas investigadas. El objeto era sensibilizar a los jefes, con el 
acuerdo de que no se malinterpretara el informe, ya que reflejaba una rea- 
lidad lastimosa sólo se hablaba de la parte negativa. Pero se les aclaró que 
la razón de esto era encontrar las causas a fin de subsanar las deficiencias 
detectadas, lo cual redundaría en beneficio de todos. Se les hizo saber que 
sin lugar a dudas la mayoría de las cosas eran positivas dentro de la instala- 
ción, pero que el reto era atacar las negativas. 

El primer paso para lograr lo anterior era aceptar o desmentir las defi- 
ciencias señaladas. Se acordó que se iban a analizar punto por punto hasta 
lograr un consenso general sobre los problemas reales, y apartar aquellos 
que resultaran aparentes. Al final de la reunión se concluyó que la mayo- 
ría de los puntos eran verdaderos. Esto representó el primer gran avance, 
es decir, la aceptación de que la investigación era veraz. 

Se tuvo mucho cuidado de no aventurar de manera precipitada estra- 
tegias de solución, ya que esto se había intentado un sinfín de ocasiones 
sin haber logrado los resultados deseados. 

Ahora el siguiente paso era identificar las causas reales, incluso apa- 
rentes, a fin de partir de bases firmes hacia la determinación de las posi- 
bles opciones de solución. 


REMOCIÓN DEL HISTORIAL 
DEL CENTRO DE CÓMPUTO 


De momento caí en un dilema, ¿Por qué existían tantos errores, aun 
cuando el personal del centro de cómputo era de buen nivel?, ¿por qué no 
había resultado efectiva ninguna estrategia de solución, o habiendo sido 
efectiva al principio, luego decaía?,¿por qué si todos los puntos que se 
encontraron eran conocidos, y ante los ojos de losjefes resultaban obvios, 
no mejoraban las cosas de una manera permanente? 

Conclui que cualquier estrategia tradicional de solución que yo reco- 
mendara seguramente ya se había intentado, y por su puesto no habría 
sido necesaria semejante investigación para simplemente decir: “señores, 
pónganse a trabajar de una manera más profesional y verán que todos los 
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problemas desaparecerán”. No, esto no solucionaría nada; es más, la 
mayoría del personal se desempeñaba con un alto sentido profesional. 
Entonces, ¿cuál podría ser la solución adecuada? o peor aún: ¿no existía 
solución?, ¿era un mal necesario? 

Poco a poco me encaminé hacia una idea, que en principio ya había 
desechado en varias ocasiones; pero al no encontrar mejor opción decidí 
acogerla con el convencimiento previo de que ahí encontraría algo. 

La idea consistía en acudir al historial del centro de cómputo con el 
propósito ya más claro de que las verdaderas razones de los problemas ahí 
estaban, y que por lo mismo no eran fácilmente identificadas por el perso- 
nal actual, ya que la mayoría era de reciente ingreso. Por esto, me dirigí al 
personal de mayor antigúedad, que por suerte ocupaba los puestos de más 
alto nivel. Por supuesto que al principio no resultó fácil, ya que había 
mucha renuencia a proporcionar información que a veces se calificaba de 
confidencial. Poco a poco fui construyendo el rompecabezas. Me pude 
valer de varios documentos y memorandas que conseguí, y encontré lo 
siguiente: 

Aproximadamente entre cinco y seis años atrás, el centro de cómputo 
se había formado con las siguientes áreas: 


tropa 


El flujo de actividades era simple; más o menos se comportaba como 
sigue: 


222 


| 


as] 
amn 


Por espacio de dos años aproximadamente el esquema fue el mismo, 
y aunque hubo algunas variantes, éstas no fueron significativas. Sin 
embargo, con la aparición de los sistemas on line súbitamente el panora- 
ma cambió, y la organización del centro de cómputo adquirió la siguien- 
te estructura: 
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Los efectos fueron los siguientes: 


+ Hubo cambio de organización. 

+ Se establecieron especialidades. 

e Los procedimientos de control variaron drásticamente. 

+ Se establecieron nuevos estándares de trabajo. 

+ Se incrementó el número de usuarios. 

+ Se incrementó la configuración del equipo de cómputo. 

+ Las cargas de trabajo aumentaron, ya que varios sistemas batch pasa- 
ron a ser on line. 

+ El personal del centro de cómputo aumentó a 28. 


Como se notará, dentro de la institución el centro de cómputo adqui- 


rió más importancia, ya que alcanzó el nivel de gerencia. 


Transcurrido un año más o menos, cuando esta nueva estructura 


todavía no se consolidaba plenamente, el impacto de las bases de datos y 
los adelantos en el hardware y software volvieron a conformar una nueva 
estructura en el centro de cómputo; (véase pág. 225). 


Los efectos fueron los siguientes: 


+ Cambio de organización. 

+ Cambio de procedimientos de control. 
+» Cambio de métodos de trabajo. 
+ Cambio de funciones y responsabilidades. 

+ Las cuotas de producción se elevaron. 

e Se abrieron más horarios de servicio. 

+ Hubo más usuarios. 

+ El personal del centro de cómputo aumentó a 40. l 


Obsérvese que ahora el centro de cómputo participa en el nivel de 


subdirección dentro del esquema organizacional de la institución. 


Esta organización fue también temporal, pues en lapsos de tiempo 


breves cambió dinámicamente hasta alcanzar el nivel de dirección gene- 
ral, bajo la cual existían varias subdirecciones, de las cuales, para abreviar, 
sólo se esquematizan dos de ellas; la complejidad de su estructura salta de 
inmediato a la vista. Estas dos subdirecciones, de entre las seis que exis- 
tían al momento de realizar la investigación, se conformaban como se 
ilustra en las páginas 226 y 227. 
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Al momento de la investigación, en la situación destacaba lo siguiente: 


e La cantidad de controles era muy complicada y confusa. 

« Las funciones, responsabilidades y límites de acción no estaban claros. 
+ De alguna manera se presentaban confrontaciones entre áreas. 
+ La organización requería cerca de setenta personas. 

e El tipo de errores se diversificó y la cantidad se incrementó. 


Con base en los datos que arrojó la búsqueda en el historial del cen- 
tro de cómputo, detecté indicios de lo que sucedía en dicha instalación. 
Era, con mucho, consecuencia de las circunstancias bajo las cuales se 
fue creando la compleja estructura del centro; pero más importante aún, 
de la tremenda improvisación que originó este crecimiento, para el cual 
no había existido previsión, ni mucho menos una estrategia planeada; es 
decir, se adoptó una tecnología nueva en forma tan rápida que la prepa- 
ración de los técnicos se fue adquiriendo vasi de manera emergente sin 
haber dedicado el tiempo necesario para establecer estrategias de con- 
trol y de administración de los recursos técnicos, humanos y materiales. 
Por eso no se adquirió madurez; el objetivo básico se centró en explotar, 
a como diera lugar, dicha tecnología. Y efectivamente, hubo resultados a 
corto plazo, pero a un costo muy elevado. Esto se convirtió en un modo 
permanente de trabajo. Hasta ahora, las cosas siguen casi iguales, y aun- 
que es cierto que se ha intentado una mayor eficiencia en la explotación 
de los recursos técnicos, poco se ha logrado, debido a que se ha arraigado 
el método de trabajo de muchos años, 

Las observaciones concretas a las que se llegó después del análisis his- 
tórico del centro de cómputo las resumi como sigue: 


+ Dentro de una organización (la de la empresa) había nacido otra 
organización (la del centro de cómputo). 

+ La organización del centro de cómputo se fue creando por etapas y 
en forma improvisada. 

+ Cada área se autoadministraba con una independencia casi total. 

» Resultaba muy difícil comprender la interrelación global de todas 
las áreas del centro de cómputo. 

+ El esquema organizacional sigue móvil actualmente. 


Como consecuencia delo anterior, derallé un documento que deno- 
miné “Resultados finales de la investigación”, el cual contenía todo lo 
expuesto en el informe preliminar, analizado anteriormente con los 
jefes de cada área, lo cual daba veracidad acerca de la deteriorada situa- 
ción que en dicho documento se reflejaba, avalado por las firmas de cada 
uno de los jefes. También incluí la explicación de las conclusiones sur- 
gidas en el historial. 
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El documento se lo entregué al directivo solicitante de la investiga- 
ción, quien me pidió una semana para revisarlo con detenimiento, bajo el 
acuerdo de que no lo comentaría con ninguno de sus subalternos, hasta 
que él y yo tuviéramos claramente definidas las medidas a tomar. 

ranscurrida la semana, acudí a la cita previamente acordada, y me 
encontré ante un directivo sumamente serio; con tranquilidad me pidió 
que fuéramos a la mesa de juntas. Me dijo: “He leído una y otra vez este 
documento, y conforme más lo repaso, menos lo entiendo”, esperó un 
momento, y corrigió: “Mejor dicho, menos lo quiero entender; siento que 
lo que me quieres decir es que mi centro de cómputo no está administra- 
do; ¿te das cuenta de lo que eso significa para mí? ¿Me quieres decir que 
no he cumplido con mi trabajo?”. Levanté la mano en señal de pedir la 
palabra, y le dije con voz tanquila: “Señor director, yo no he imaginado 
siquiera que usted no ha cumplido con su trabajo, sin embargo, usted ya 
lo dijo, su centro de computo no está administrado, y créame que después 
de mucho analizarlo ésta fue la conclusión rotunda a la que he llegado. 
Aunque como lo habrá notado, tal aseveración no está en ninguna parte 
del documento que tiene en sus manos; pero resulta sorprendente que lo 
que usted ha intuido precisamente es lo que explico en este nuevo docu- 
mento que le traigo; en donde también, según mi particular punto de vis- 
ta, establezco la única solución viable que se me ocurre, Por supuesto, he 
tomado como base todos los detalles de mi investigación y basado en más 
de quince años de experiencia concluyo que será necesario experimentar 
su efectividad”. De inmediato agregué, sin dar oportunidad a que me 
interrumpiera: “por desgracia habrá necesidad de experimentar la estrate- 
gia que propongo, ya que no conozco ninguna instalación que la tenga en 
práctica actualmente, pero lo que sí le aseguro es que se basa en un hecho 
real que se ha estado aplicando desde hace mucho tiempo con resultados 
muy efectivos, pero se aplica sót» en momentos, es decir, es un remedio al 
que se ha recurrido por excepcio y no como función, y esto último es 
exactamente lo que yo establezco cc mo solución permanente para reducir 
los errores y minimizar sus efectos ¿o más posible. No garantizo que mi 
estrategía elimine los errores de su centro de cómputo, porque eso por 
desgracia no es posible, pero estay seguro que la situación debe mejorar 
sustancialmente; y algo más, si mi estrategia no es efectiva, en poco tiem- 
po se sabrá, porque de la misma manera, si en verdad es acertada, los 
resultados se verán de inmediato”. A continuación procedi a explicarle mi 
sugerencia, misma que conforme se la describía acaparaba su interés; has- 
ta que terminada mi exposición, dijo: “Me cuesta trabajo creer que la solu- 
ción sea tan sencilla, pero encuentro todas las evidencias lógicas, mismas 
que no puedo objetar, ya que demuestran un alto sentido común”. Luego 
agregó: “Sobre todo, lo que más me impresiona es que su puesta en mar- 
cha resulta considerablemente económica, por lo cual aunque no diera 
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los resultados deseados bien vale la pena experimentarla. Sin embargo, 
todo parece indicar que algún buen resultado se puede esperar de esto". 

La estrategia se puso en marcha en forma paulatina, y aunque no ha 
pasado mucho tiempo, los resultados positivos han sido inmediatos; y se 
puede percibir que si la estrategia no es abandonada, posiblemente esté 
abriendo un nuevo campo de acción para los informáticos. Dicha estrate- 
gia se describe a continuación. 


PROPUESTA DE SOLUCIÓN 


Crear un área ex profeso para la ad 
to como staff de la dirección, 

El objetivo de esa área será implantar un mecanismo administrativo 
completo, en el cual se considere la organización del centro de cómputo 
en su entorno global. 

La función del área será hacer el seguimiento a cualquier evento pro- 
blema que tenga que ver con la responsabilidad y/o servicio del centro de 
cómputo. 

La estrategia es que dicho seguimiento sea permanente desde el 
nacimiento del evento hasta lograr su control, y dejar establecido un 
procedimiento confiable de prevención. 


istración del centro de cómpu- 


ARGUMENTOS DE LA PROPUESTA 


Cuando existe algún problema en el centro de cómputo, y éste es 
atendido, invariablemente es resuelto. En otras palabras, no existe un pro- 
blema en el ambiente de cómputo en el que de alguna manera no haya 
una opción de solución. 

Se ha comprobado que cualquier área problema del centro de cómpu- 
to, a la cual se le asigna un auditor, en corto tiempo normaliza su funcio- 
namiento. 

Proyectos complejos del ámbito computacional que fueron adminis- 
trados en forma permanente durante su desarrollo, se han realizado con 
un alto grado de eficiencia. 

Lo anterior demuestra que mientras existe un seguimiento efectivo, 
hay avance positivo. Por otro lado: 

Si un problema se ataca, pero no se deja establecida una estrategia de 
control, vuelve a aparecer. 

Si se establece una estrategia de control y no se le da seguimiento para 
su cumplimiento, pronto se abandona. 

Proyectos administrados y culminados exitosamente, pero que se des- 
cuidan, con el tiempo decaen. 
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Lo anterior significa que si no se establece el seguimiento efectivo y 
permanente, se tiende al retroceso. 

En función de los argumentos anteriores, llegué a la conclusión de 
que el concepto de seguimiento es el mecanismo más importante dentro 
del contexto de cualquier función administrativa. Obsérvese la siguiente 
definición y la equivalencia que descubro, como carta válida de la eficien- 
cia administrativa. 

La definición que se da del concepto administrar, en forma sintética, 
es la siguiente: establecer mecanismos de control necesarios para el cum- 
plimiento de actividades. Lo que en otras palabras menos científicas equi- 
vale al seguimiento, Pero no un seguimiento por excepción, sino como 
función, ya que eso es lo que reclaman los mecanismos de control. 

Lo anterior me llevó a otro descubrimiento no menos importante, del 
que existe suficiente evidencia en los resultados de mi investigación. La 
mayoría de los errores detectados en el centro de cómputo investigado eran 
atendidos al momento de surgir, y se hacía un seguimiento persistente 
durante la búsqueda y aplicación de la solución. Una vez encontrada ésta y 
aplicada, en donde a veces intervenían técnicos que no pertenecían al área 
en la cual se había presentado la falla, ahí terminaba todo; se salía del apuro y 
el problema se daba por concluido. No se realizaba un análisis serio a fin de 
detectar las causas y sobre todo, dejar establecido un procedimiento de con- 
trol para asegurar que dicho error quede controlado en el futuro. 

Está claro que siempre se acudía a un seguimiento por excepción, diri- 
gido meramente a la corrección momentánea y no al establecimiento de 
controles en función de las causas. Un esquema de esto se muestra a con- 
tinuación: 


Impacto 


Errores en el tiempo 
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Como se puede apreciar, con un seguimiento por excepción la canti- 
dad de errores es frecuente y su impacto es elevado. Prácticamente, al no 
analizar las causas y no establecer los controles, la probabilidad de que un 
mismo tipo de error se presente de nuevo es alta; y sumada la frecuencia, 
el impacto se vuelve crítico. 

Por otro lado, al estructurar un área cuya estrategia sea el administrar 
el centro de cómputo en su entorno global, y que se lleve a la práctica 
mediante un seguimiento como función, el esquema Cebe comportarse 
como sigue: 


¡ren SS 


Errores on ol tempo 


Todo error tratado de esta manera, es decir, donde se analice, corrija y se 
deje un procedimiento de control, tenderá necesariamente a su eliminación, 
o cuando menos, a su aparición en espacios de tiempo más aislados. La apari- 
ción repetida en este caso puede obedecer a la misma dinámica de los siste- 
mas. Al cambiar éstos, pueden hacer que un procedimiento establecido ya no 
sea adecuado. El impacto tiende a minimizarse. La explicasión gráfica de 
este efecto se muestra en el siguiente esquema, al que he den minado Mode- 
lo de aprendizaje por seguimiento como función. (véase pág. 233). 

Cabe señalar que la estrategia que propongo es simple, y se puede 
apreciar con claridad que los resultados positivos de la misma necesaria- 
mente tienen que darse en el corto plazo. 

Al no conformarme con establecer la estrategia de la cual ya no tenía 
duda de su eficiencia, todavía fui más allá. Comparé este estudio con los 
ambientes de otros centros de cómputo. Lo que encontré se ilustra en la 
página 234. 


Modelo de oprendizoje por seguimiento como función 
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DETENI 


Comparcción del estudio. 


A cambio de: 


Instalación-5 pp 
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En resumen, se observa que el panorama en otras instalaciones 
(centros de cómputo) no es tan distinto; con la aclaración de que esto 
es en relación con el tipo de errores detectados en la primera investiga- 
ción. Es preciso subrayar que aquí no se destaca el grado de eficiencia 
logrado en las distintas instalaciones; más bien se señalan los proble- 
mas, los que en gran medida demeritan el nivel positivo alcanzado, 
pues recuérdese que el objetivo del estudio es controlar los errores; por 
consiguiente, al lograrlo, automáticamente la eficiencia de cualquier 
centro de cómputo se eleva. 

Como subproducto de la investigación, confirmé algo que con 
frecuencia se pierde de vista, y que bien vale la pena s abrayar. El cen- 
tro de cómputo es un área de servicio, cuyo objetivo es apoyar al resto 
de las áreas de la organización. Por tanto, debe hacerse conciencia de 
lo siguiente: 


El 10% de la productividad del personal del centro de cómputo debe ver 
hacia adentro. 


El 90% restante debe proyectarse hacia afuera. 


La aseveración anterior obedece a que el trabajo del técnico en infor- 
mática es tan apasionante, creo yo, y por tratarse de una tecnología nove- 
dosa y en constante auge, aquél se llega a enfrascar en la idea de que sus 
actividades se circunscriben al ambiente interno del centro de cómputo, 
sin darse cuenta de que el beneficio de la eficiencia de su trabajo se produ- 
cirá fuera de dicho centro. Ejemplo: obsérvese a un programador cuando 
está satisfecho por una solución ingeniosa que encontró en la elaboración 
de un programa. Sus expresiones se inclinan a comentar los detalles téc- 
nicos y de lógica que utilizó, pero no destaca la importancia del servic 
EA a programa. Es decir, su princi- 
pal interés se mantiene en el ámbito técnico. El usuario no pertenece a 
este medio. Normalmente se descuida que la razón primordial de la exis- 
tencia de un centro de cómputo es el usuario. En este punto, cabe men- 
cionar los siguientes niveles de usuarios: 


a) Usuarios de nivel directivo. 
b) Usuarios de nivel operativo. 
e) Usuarios finales (clientes, proveedores, etc.) 


La eficiencia del centro de cómputo, en cuanto a la calidad y oportu- 
nidad de la información que genera, representa un poderoso eslabón, el 
cual unido a la cadena de los servicios que presta la empresa o institución, 
conforma el siguiente esquema: 


ARGUMENTOS DE LA PROPUESTA 237 


La poca pero sustanciosa experiencia que ha demostrado la estrategia 
aquí expuesta, dado su corto periodo de aplicación, permite dar a conocer 
que es más rápido llevar a un técnico a realizar labores administrativas 
que convertir a un administrador en técnico; por eso se recomienda, en 
espera de que el sector educativo genere administradores de centros de 
cómputo, que por el momento las personas que integren el área adminis- 
trativa del centro se apeguen lo más posible al siguiente perfil: 


1. Deben tener una experiencia técnica de cuando menos 10 años. 

2. Serán candidatos prioritarios los que hayan participado como sis- 
tem programmers. La razón es que incluso en la actualidad el perso- 
nal de soporte técnico es asesor de algunas otras áreas del centro de 
cómputo, lo cual demuestra que tiene ya un cierto reconocimiento 
dentro de la instalación, 

3. Es indispensable que hayan fungido como líderes de proyectos de 
importancia. 


A lo anterior me gustaría agrezar los siguientes comentarios de 
importancia. En cierta ocasión, alguien con quien intercambiaba impre- 
siones sobre la estrategia que recomiendo, me decía lo siguiente: “Perfec- 
to, tu estrategia sí convence, pues cuenta con un razonamiento profundo, 
que incluso invita a la reflexión. Al mismo tiempo, pone de manifiesto tal 
cantidad de situaciones obvias y conocidas por ¡ole tira que no es 
posible refutarlas”, Luego agregó: “Todo parece tan obvio, incluso tu 
recomendación; y creo que ahí radica el secreto, es decir, es tan trivial que 
precisamente a nadie, que yo sepa, se le había ocurrido, sobre todo porque 
resulta tan sencillo que se antoja que no merecía importancia”. Y aún 
abundó más: "Yo lo describiría semejante a lo que alguna vez leí: «como 
un tremendo destello de lo cbvio, que produce ceguera». Y continuamos 
metidos en el mismo agujero desde hace años”. Finalmente, con una leve 
ironía apuntó: “Pero, ¿me quieres decir de dónde sacaremos a los super- 
hombres que se requieren para estructurar el área administrativa del cen- 
tro de cómputo”. 

No me incomodó su pregunta; con plena seguridad le contesté: 
“Resulta que no se tendría que buscar demasiado, porque esos superhom- 
bres, como tú los llamas, hace años que se encuentran en las instalacio- 
nes. El problema está en que se han dedicado a hacer el seguimiento por 
excepción, y además están tan escondidos dentro de la organización que 
prácticamente no se les toma en cuenta. ¿Sabes a quiénes me refiero?, son 
aquellos del área gris de métodos y procedimientos. Algunos otros reali- 
zan las labores de seguimiento de problemas, mismas que a nadie importa. 
ahí están desde hace años, haciendo un trabajo insignificante ante los 
ojos de las demás áreas. ¡Sí, ahí están!" 
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CONCLUSIONES 


Si usted leyó con detenimiento este libro, recordará que en el pró!əgo 
mencioné que cuando llegara al final usted habría adquirido mucho de la 
buena "educación informática”. Pero también mencioné que sólo llegaría 
hasta una gran puerta que se abriría automáticamente y que al encontrar- 
se del otro lado ésta se cerraría por un mecanismo que ya no permitiría su 
regreso. Asimismo, aclaré que encontrándose del otro lado, su trayecto 
apenas comenzaría, y que sería mucho más dificil el camino por andar 
que el ya andado. Pues bien, usted ya se encuentra del otro lado. Ahora 
con el conocimiento que ya adquirió, le pregunto lo siguiente: 


¿Esta dispuesto a continuar? 


No conozco su respuesta, pero yo lo invito a que continúe. Si usted es 
un técnico o profesional en informática ya en ejercicio, encuentre la exce- 
lencia informática y convierta su actividad en excelente. Si usted es estu- 
diante de esta especialidad, aprecie el vasto campo de acción y participe 
con una nueva mentalidad, decidido a fortalecer el nivel tecnológico de 
nuestro país. 

Conseguir la meta del presente trabajo realmente depende de usted. 

Para terminar sólo agregaré una frase que ya he utilizado en otras oca- 
siones y quiero compartir, por la gran verdad que de ella emana: 


La esencia de todo propósito no está en el ímpetu con el que se inicie, 
sino en la persistencia para su realización. 


Apéndice. Descripción 
de responsabilidad y 
funciones por puesto, 
de acuerdo con el 
organigrama de una 
subdirección de 
automatización 
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Objetivo 


Este documento permite la estructuración 
completa de la organización funcional de una 
subdirección de automatización, con respecto 
a los requerimientos de las áreas 
especializadas y recursos humanos necesarios 
para cubrirlas. Asimismo, permite la ubicación 
del personal existente, de acuerdo con sus 
habilidades, y en consecuencia, los 
requerimientos de contratación necesarios. 


Cuando no están definidas claramente las funciones y responsabilidades, se 
fomenta la “todologia” 


A través de la descripción de la responsabilidad a cubrir por cada área, y vislumbrando 
las funciones a desarrollar, se puede comprobar la justificación de cada puesto. 


Dlograma funcional de la subdirección de cutomotización 


Suboiección 
automatización 
I mat 1 1 
Gorancia Gerencia de Gerencia Gerencia 
de consultoria de de 
desarroilo técnica servicios ¿esarrolo 
de sistemas a usuarios de cómputo técnico 


Gerencia de desarrollo 
de sistemas 


PUESTO: GERENCIA DE DESARROLLO 
DE SISTEMAS 


Descripción 


Es la responsable de automatizar los requerimientos de información de aquellas unida- 
des usuarias que por el alcance de sus operaciones dentro de la institución, volúmenes de 
datos y requerimientos especificos de servicio, necesitan ser satisfechas mediante el desa- 
rollo de sistemas complejos. o el aprovechamiento del banco de datos centralizado en el 
computador principal, 


Desarrollo de funciones 
De planeación: 


a) En conjunto con el usuario y en coordinación con la gerencia de consultoría técnica a 
usuarios, precisan objetivos, alcances, normas y políticas que regirán cada sistema, 

b) En conjunto con el subdirector de automatización y los directivos de las unidades 
usuarias, analizan el alcance posible de los proyectos de sistemas que consideren 
inversiones no previstas con anterioridad, a fin de lograr su autorización 

c) Participa en la planeación para que los requerimientos de hardware y software que 
estarán involucrados en el desarrollo de los sistemas, se encuentren disponibles en 
las fechas en que serán utilizados. Esto lo hace en coordinación con la gerencia de 
desarrollo técnico. 

d) Establece, junto con el usuario, el plan estratégico para el iniciu y desarrollo de los 
sistemas por diseñar. 

£) Analiza las cargas de trabajo del personal bajo su dirección, establece los equilibrios 
necesarios, en función de los requerimientos de cada sistema. 

A Formaliza compromisos en el apego a la capacidad y disponibilidad de su personal. 

8) Asigna los proyectos para los coordinadores de sistemas, en función de la politica de 
servicio de cada sistema. 
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De administraci 


a) Participa en el desarrollo de metodologías de trabajo ex profeso, para su área de 
acción 

b) Evalúa la funcionalidad de los métodos de trabajo establecidos. y regula las deficien- 
cias detectadas. 

e) Se asegura de que los métodos de trabajo establecidos sean respetados y puestos en 
práctica. 

) Observa que los procedimientos establecidos conduzcan a trabajos con la calidad 
suficiente, y que permitan labores de mantenimiento seguras y bajo control. 

e) Establece mecanismos de medición que le permitan detectar a tiempo desviaciones 
en los calendarios de compromisos, para establecer correctivos oportunos. 

A Evalúa periódicamente el nivel técnico de su personal, y analiza si es congruente con 
la magnitud de los proyectos en cartera, o en su defecto, la tendencia de éstos, para 
establecer los requerimientos de capacitación necesarios, haciendo las solicitudes. 
correspondientes a la gerencia de desarrollo técnico. 

Æ Lleva registro sistemático de fallas en sistemas puestos en producción, y las analiza 
para determinar las causas y acciones a seguir. 

M) Evalúa en forma periódica el desempeño de los recursos humanos. y establece planes 
de Incentivos para evitar rotación de personal. 

N Periódicamente coordina juntas con los usuarios, para percatarse de que los resulta- 
dos que éstos reciben satisfacen los requerimientos de información, tanto en oportu- 
nidad como en calidad. 

D Informa de compromisos adquiridos, avances, logros. requerimientos y cualquier dato 
de Importacia para el subdirector de automatización 


Técnicas: 


Participa en seminarios técnicos que le permitan conocerla evolución delos recursos de 
cómputo para que los diseños se apeguen a los métodos modernos. 


PUESTO: COORDINADOR DE SISTEMAS 


Descripción 


Es el responsable de cubrir los requerimientos de información de un módulo específico. 
dentro del ámbito de la compañía. 


Desarrollo de funciones 
De planeación: 


a) En conjunto con el gerente de desarrollo de sistemas, analiza los objetivos, alcances, 
normas y políticas que regirán al sistema, a fin de establecer la bases para el diseño. 

2) En conjunto con el gerente de desarrollo de sistemas, verifica la disponibilidad de 
recursos técnicos y humanos, para estructurar un plan maestro de actividades que 
garanticen la correcta consecución del mismo. 

©) En conjunto con los usuarios, establece las responsabllidades mutuas para el desa- 
rrollo de cada sistema. 
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d) Lleva a cabo la asignación del sistema para el lider de proyecto correspondiente. 
e), En conjunto con el lider de proyecto, analiza el plan maestro y establece fechas de 
compromiso. 


De administración: 


a), Vigila que las actividades establecidas en el plan maestro sean cubiertas cabalmente. 
b) En conjunto con ellider de proyecto correspondiente, inicia las visitas a usuarios directi- 
vos a fin de empezar con pláticas de detalle para el inicio del diseño del sistema, 
+), Verifica que el desarrollo de todo sistema se apegue a la metodología detallada esta- 
blecida para tal fin. 

d) Administra el control de actividades y calendarios de los lideres de proyecto, para 
vislumbrar desviaciones y detectar causas y opciones de solución. 

€) Leva informes de avances para mantener informado al gerente de desarrollo de sis- 
temas. 

N) Coordina juntas con los usuarios directivos. para precisar los resultados de cada sis- 
tema. 

8) Lleva a cabo presentaciones de avance hacia los usuarios directivos, para lograr 
congruencia de actividades durante el desarrollo del sistema. 

A), Supervisa y autoriza el control de cambios alos sistemas bajo su responsabilidad, 


Tócnicas: 


Participa en seminarios técnicos que le permitan conocer la evolución de los recursos de 
cómputo, para que los diseños se apeguen a los métodos modernos. 


PUESTO: LÍDER DE PROYECTOS 
Descripción 


Es responsable del diseño, programación y mantenimiento de varios sistemas de un mis- 
mo tipo, 


Desarrollo de funciones 
De planeación: 


a) Realiza visitas y entrevistas a nivel de usuarios operativos. para elaborar el diseño 
conceptual de cada sistema. 

b) Establece el plan detallado de actividades para todo sistema, en conjunto con los 
analistas programadores. 

©) En conjunto con los usuarios operativos, analiza la utilidad práctica delos resultados 
a obtener por cada sistema 

d) Descompone en módulos cada sistema. y establece prioridades de desarrollo acorda- 
das con el usuario. 

e) Asigna cada módulo al analista-programador correspondiente. 

En conjunto con los usuarios, establece el plan de implantación de cada sistema por 
liberar, 


De administración: 
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4) Administra los calendarios de detal. de manera que no existan retrasos. 

È) Verifica que el desarrollo de cada sistema se apegue alos estándares de documenta- 
ción establecidos. 

6) Verifica que las pruebas de módulos e integrales cubran todas las condiciones deter- 
minadas para el proceso de los datos de cada sistema. 

d) Viella que la calidad del diseño y programación se sujete a los estándares Lécnicos 
establecidos. 

e) Lleva a cabo presentaciones al usuario sobre ejemplos de los resultados obtenidos en 
las pruebas. 

A En conjunto con el usuario. administra la puesta en marcha de los módulos de cada 
sistema, 

8) Viglla que el mantenimiento de los sistemas se leve a cabo por medio de un control 
efectivo de cambios. 


Técnicas: 


a) Desarrolla el diseño conceptual de cada sistema. 

b) Participa en cursos específicos sobre las facilidades técnicas del equipo de cómputo. 
para que sus diseños consideren las facilidades que tiene disponibles. 

c) Se mantiene informado sobre paquetes de software que existen en el mercado, para 
abreviar el diseño de algunos sistemas. 

4) Participa en seminarios de actualización que le permitan conocerla evolución de los 


recursos de cómputo para que los diseños y la programación scan más electivos y. 
confiables. 


PUESTO: ANALISTA-PROGRAMADOR 


Descripción 


Es responsable del diseño detallado y de la programación de Jos módulos de un sistema 
asignados a él. 


Desarrollo de funciones 
De planeación: 
a) Realiza investigaciones y entrevistas a nivel usuario operativo, para desarrollar el 
diseño detallado de los módulos del sistema asignados a él 
b) Elabora el calendario de actividades detallado para el diseño y programación de los 
módulos asignados a él. 


De administración: 


a) Administra su tiempo en función de las actividades a cubrir a fin de cumplir con las 
fechas de compromiso. 
b) Coordina las pruebas con el usuaria de los módulos por liberar. 


Técnicas: 


8 


m 
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Desarrolla el diseño detalado de los modulos del sistema asignados a él. 
Desarzolla la definición de cada programa resultante del diseño detallado, 
Documenta el diseño detatado con base en los estándares establecidos. 

Lleva a cabo la programación y prueba de cada programa resultante del diseño deta- 
lado, y lo documenta. 

Realiza la prueba integral de cada módulo asignado a él. y la valida. 

Capacita técnicamente a los usuarios en la implantación de los módulos del sistema 
asignados a él 

Participa en cursos específicos sobre las facilidades técnicas del equipo de 
cómputo para que sus diseños y programación consideren las facilidades que tie- 
ne disponibles. 

Paruicipa en seminarios de actualización que le permitan mejorar sus diseños y pro- 
gramación. 

Imparte cursos específicos de su área de acción, a analistas y programadores de 
muevo ingreso a la Instalación 

Realiza el mantenimiento necesario para los módalos responsabilidad de él a fin de 
que los resultados de los mismos siempre sean satisfactorios para las necesidades 
cambiantes de los usuarios. 


PUESTO: MESA DE CONTROL Y 
RESGUARDO DE DOCUMENTACIÓN 


Descripción 


Es responsable de resguardar, controlar, depurar y actualizar la documentación corres- 
pondiente a cada sistema, 


Desarrollo de funciones 


Do planeación: 
No realiza funciones de planeación. 
De administración: 


a) 
D 
e 


Centraliza la documentación integra! de cada sistema. 

Actualiza la documentación con los cambios que le reportan. 

Depura la documentación obsoleta. bajo autorización del gerente de desarrollo de 
sistemas. 

Lleva registro de la documentación existente. 

Controla la documentación que le solicitan, y la recupera. 

Mantiene la existencia de papeleria y artículos varios para el trabajo del personal de 
la gerencia de desarrolla de sistemas, y los reparte en forma racional. 

Archiva y controla la documentación administrativa de apoyo a la gerencia de desa- 
rrollo de sistemas (ejemplo: hojas de control de cambios. control de proyectos. repor- 
tes estadísticos, solicitudes de usuarios. reportes de fallas, etc. 


Técnicas: 


No realiza funciones técnicas. 


Estructura específica de lo gerencia de desarrollo de sistemos 


Gerencia de 
desarroilo. 
de sistemes 
£ I I 
Coordinador Coordinador Coordinador 
de de de sm 
sistemas sistomas sistemas 
Módulo Módulo "B" Modulo “C 
T I I 
Lideres Lceres Lores 
de de de 
proyectos proyectos proyectos 
J E E 
Pool de analistas programadores ] 


Gerencia de 
consultoría técnica a 
usuarios 


PUESTO: GERENCIA DE CONSULTORÍA 
TÉCNICA A USUARIOS 
Descripción 


Es la responsable de asesorar a las unidades usuarias para determinar el tipo y nivel de 
tecnología que satisfaga sus requerimientos de Información, y encaminarlos hacia la opción 
más apropiada. Esta Área es la que Integra al usuario a los servicios de cómputo. 


Desarrollo de funciones 
De planeación: 


a) En conjunto con el usuario, analiza los requerimientos especificos de información 
solicitado: 

b) Determina si los requerimientos de información pueden ser satisfechos por el desa- 
rrollo de algún sistema a ser procesado en el equipo de cómputo central, y participa 
en la delegación del proyecto hacia la gerencia de desarrollo de sist 

©) Determina si los requerimientos de información del usuario deberán ser satisfechos 
por equipo y software autónomo al computador central. 

0) En conjunto con el subdirector de automatización y con los directivos de as unidades 
usuarias solicitantes, analiza la inversión requerida para la adquisición de equipo y 
determina las posibilidades de alcance para lograr la autorización 

e) Participa en la planeación para que los requerimientos de hardware y software que 
estarán involucrados en el proyecto. se encuentren disponibles en las fechas plane 
das. Esto lo hace en coordinación con la gerencia de desarrollo técnico. 

N) Establece en conjunto con el usuario, el plan estratégico para el inicio y desarrolo del 
proyecto, 

8) Analiza las cargas de trabajo del personal que está bajo su dirección, y establece los 
equilibrios necesarios en función de la magnitud de cada proyecto. 

h) Formaliza compromisos en apego a la capacidad y disponibilidad de su personal. 

1 Asigna los proyectos al personal a su cargo. 


PES PERSEBRIA DUE CONSULTORIA TECNICA 
De administración: 


a) Participa en el desarrollo de metodologías de trabajo dirigidas a su área de acción. 

b) Evalúa la funcionalidad de los métodos de trabajo establecidos, regula las deficien- 
cias detectadas. 

©) Se asegura que los métodos de trabajo establecidos sean respetados y puestos en 
práctica. 

d) Observa que los procedimientos establecidos conduzcan a trabajos con calidad sufi- 
ciente y que permitan labores de mantenimiento seguras y bajo control. 

e) Establece mecanismos de medición que le permiten detectar a tiempo desviaciones 
en los calendarios de compromisos. a fin de establecer correctivos oportunos. 

/ Evalúa periódicamente el nivel técnico de su personal, y analiza si es congruente con. 
la magnitud de los proyectos en cartera, o en su defecto, la tendencia de éstos, para 
establecer los requerimientos de capacitación necesarios, y hace las solicitudes pere 
tnentes a la gerencia de desarrollo técnico. 

£) Lleva registro sistemático de las fallas de los sistemas detectadas por los usuarios, y 
analiza para determinar cuáles son las causas y las acciones a seguir. 

h) Evalúa en forma periódica el desempeño del personal, y establece planes de incenti- 
vos para evitar rotación de personal. 

A) Periódicamente coordina juntas con los usuarios para percatarse de que los resulta- 
dos que éstos obtienen satisfacen los requerimientos de información predefinidos, 

Ì Elabora informes de compromisos adquiridos, avances, logros. requerimientos y 
cualquier dato de importancia para el subdirector de automatización. 


Técnicas: 


Participa en seminarios técnicos de actualización, para conocer nuevos equipos y 
Paquetes disponibles que ofrezcan a los usuarios más ventajas operativas y de información. 


UESTO: CONSULTOR DE MÉTODOS 
Y PROCEDIMIENTOS 


Descripción 


Es responsable de asesorar técnicamente a los usuarios para sistematizar sus requeri- 
mientos de Información, ya sea optimizando los procedimientos de trabajo o por medio de 
equipos de cómputo para oficina 


Desarrollo de funciones 
De planeación: 


a), En conjunto con el usuario, analiza las requerimientos especiñios de información para eva- 
luar la utilidad que Éstos representan, tanto en calidad como en oportunidad. 

b) En conjunto con el usuario. analiza los volúmenes de datos a procesar, para vislum- 
brarsise requiere la mecanización de éstos y el tipo de equipo necesario, ya que pue- 
de ser sólo la instrumentación de procedimientos administrativos y equipo especial 
de oficina lo requerido para satisfacer las necesidades de información. 

e), En caso de que la solución sea un computador de oficina, participa en coordinación 
con el usuario para elaborar un plan de actividades conjuntas. 
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De administración: 


En conjunto con el usuario, administra el plan de actividades para cubrir las fechas de 
Compromiso. 


Técnicas: 


a) Asesoría técnica al usuario para la elaboración del manual de métodos y procedi- 
plentos, cuando se trate del desarrollo de un sistema administrativo. 

b) Asesoría técnica al usuario en la implantación de un sistema administrativo, 

£) Asesoría técnica al usuario para la elaboración del manual de requerimientos de 
automatización. Esto es para cuando se use un computador para oficina, 

4) Presentación del manual de requerimientos de automatización al gerente de consul- 
toria técnica, para tramitar la adquisición de software y hardware a través de la 
gerencia de desarrollo técnico. 

e) Si os necesario desarrollar un sistema por la falta de un paquete de sofware que 
satisfaga los requerimientos de información. o porque resulte más costeable, se dará 
la asesoría al usuario para el desarrollo del análisis y diseño del sistema y su docu- 
mentación. 

A Participa en seminarios técnicos de actualización para conocer nuevos productos de 
hardware y software que existen en el mercado. 


PUESTO: CONSULTOR TÉCNICO 
Descripción 
Es responsable de la puesta en marcha del hardware y el software para los usuarios con 
sistemas automatizados autónomos al computador central 
Desarrollo de funciones 
De planeación: 
Elabora el plan de trabajo para la Instalación de hardware y software requeridos. 
De administración: 
a) Lleva registro de fallas en los paquetes de software contratados e instalados en los 
computadores propios de los usuarios, ast como de las correcciones. 
b) Lleva registro de los paquetes instalados en los computadores propios de los usua- 
rios y proveedores de éstos. 
Técnicas: 


2) Coordina la instalación de hardware y software en la fase de puesta en marcha, 

b) Verifica que funcionen correctamente. 

e) Coordina la capacitación técnica para la autosuficiencia de los propios usuarios. 

d) Asesora al usuario en la contratación de su propio personal técnico. 

e) Asesora al personal técnico propio del usuario cuando se trate del desarrollo y pro- 
gramación de un sistema automatizado. 
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N Realiza visitas de auditoria técnica cuando los sistemas ya están en producción. ase- 
sora al personal técnico propio del usuario cuando detecta deficiencias en la utiliza- 
ción del equipo de cómputo. 

8) Evalúa la autosuficiencia técnica del personal técnico propio del usuario, y emite dic- 
tamen y sugerencias. 

A) Imparte seminarios de informática a usuarios nuevos. 


Estructura especifico de la gerencia de consultoría técnica a usvorios 


Gerencia de servicios 
de cómputo 


PUESTO: GERENCIA DE SERVICIOS 
DE CÓMPUTO 


Descripción 


Es la responsable de mantener en forma permanente la disponibilidad de hardware y 
software en condiciones para permitir la operatividad de las unidades usuarias que reci- 
ben el servicio, además de cubrir a tiempo los calendarios de producción de los sistemas 
liberados, 


Desarrollo de funciones 
De planeación: 


a), En conjunto con la gerencia de desarroilo de sistemas. estructura los planes de servi- 
cio requeridos por las unidades usuarias. 

b) En conjunto con la gerencia de desarrollo técnico establece los planes de instala- 
ción, puesta en marcha y mantenimiento del hardware y software requeridos por 
los sistemas. 

©) Desarrolla los planes físicos considerando dimensiones locales, ubicación estratégi- 
ca de equipo. seguridad de las instalaciones. configuraciones óptimas de equipo e 
instalaciones fisicas de acondicionamiento ambiental 

49) Lleva la planeación de las cargas de trabajo, de manera que 
tiempo la posible saturación en cualquiera de los servicios de ci 
dad de él 


e pueda vislumbrar a 
imputo responsabili- 


De administración: 
a), Estabece las medidas de control y seguridad de acceso a las distintas áreas restrin- 


gidas. 
b) Participa en el desarrollo de metodologías de trabajo dirigidas a su área de acción. 


si 
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©) Evalúa la funcionalidad de los métodos de trabajo establecidos. y regula las deficien- 
cias detectadas 

d) Se asegura que los métodos de trabajo establecidos sean respetados y puestos en 
práctica. 

e) Establece mecanismos de medición que le permitan detectar con tiempo desviacio- 
nes en los calendarios de servicio y estableoer medidas correctivas, 

N) Lieva el control de facturación para los servicios de mantenimiento de hardware, 
software e instalaciones diversas, y las canaliza para su autorización cuando éstos 
son satisfechos a plenitud. 

£) Vigila que el mantenimiento dei hardware, software e instalaciones diversas, reúnan 
los rasgos de calidad que Je permitan dar un servicio coniinuo. 

b) Lleva registro sistemático de faltas de hardware, software y sistemas en producción. 
y toma las acciones necesarias para su corrección. 

A Evalúa periodicamente el nive! técnico y administrativo de su personal, y analiza sl es 
congruente con el nivel de la tecnología operada bajo su responsabilidad. Asimismo 
establece los requerimientos de capacitación necesarios para la gonencia de dosa- 
rrollo técnico. 

A Evalúa en forma periódica el desempeño de los recursos hunanos y establece planes 
de incentivos para evitar rotación de personal, 

K) Pertodicamente coordina patas con la gerencia de desarrollo de sistemas y la geren- 
cia de desarrollo técnico pera evaluar silos niveles de servicio cubren las necesida- 
des de Información de las distintas uridades usuarias. o en su defecto, estructurar 
aocionos conjuntas. 

A Recibo solicitudes de operación de mevos sistemas, variantes en los calendarios de 
servicio, instalación de hardware y software adicionales, y se asegura de que talés 
solicitudes sean satisfechas según los calendarios establecidos. 


m) Elabora informes de compromisos adquiridos. avances, logros, requerimientos y 


cualquier dato de importancia para el subdirector de automatización, 


Técnicas: 


ción 


Participa en seminarios técnicos de actualización que le permitan coordinar la explota- 
más efectiva de los recursos de hardware y software disponibles. 


PUESTO: JEFE DEL CENTRO DE 
PROCESAMIENTO DE DATOS 


Descripcion 


Es responsable de vigilar el mantenimiento sistemático del equipo de cómputo para 


lograr que el servicia sea congruente con los horarias establecidos. 


Desarrollo de funciones 


De planeación: 


a) Elatorara el plan de mantenimiento detallado del computador y de sus periféricos 
para obtener la máxima disponibilidad, 
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b) Elabora el plan de mantenimiento especifico para mantener al computador en condi- 
ciones óptimas ambientales y de limpieza. 


De administración: 


a) Lleva la administración y seguimiento para que los planes de mantenimiento del 
computador y las condiciones ambientales sean cubiertas satisfactoriamente. 

b), Lleva récord de falas de bardware y software y hace el seguimiento para que sean 
corregidas a la mayor brevedad. 

©) Elabora diariamente los horarios y servicios a ser cubiertos por el centro de cómputo, 

dh Establece las estrategias de operación, tanto del computador principal camo de sus 
periféricos, y determina los turnos de servicio. 

£) Coordina la asignación de operadores en función de turaos y tipos de servicio, 

N En casos de caidas del servicio de cómputo, además de tomar parte para una rápida 
continuidad. informa a los usuarios sobre la situación. 

4) Supervisa que los procedimientos de seguridad de las áreas restringidas sean respal- 
dados. 

h) Lleva estadisticas de servicio y prevé los horarios extra de servicio cuando los nor- 
males han sido rebasados. 

A Estructura la rotación de turnos y asignación de operadores. 

1) Leva registro de use de dispositivos magnéticos, papelería y diversos, para mante: 
ner en forma continua una disponibilidad sufieiente. 

K) Lleva informes de niveles de servicio, disponibiidad de tiempo máquina. cargas pico 
y Cualquier dato de interés para el gerente de servicios de cómputo. 

» Evalúa los requerimientos especificas de capacitación cuando detecta deficiencias 
técnicas en los operadores y reporta a la gerencia de servicios de cómputo 1 fin de 
tramitar su solicitud. 

m) implanta los métodos de trabajo específicos de su área. 


Vócnicas: 


Tarticipo en seminarios técnicos de actualización para conoser cun más detalle el poten- 
cial de servicio del equipo del cual es responsable. 


PUESTO: SUPERVISOR DE TURNO DE OPERACIÓN 


Descripción 


Es responsable de la operación del centro de computo y de cubrir los requerimientos 
específicas de servicio del turno al cual está asignado. 


Desarrollo de actividades 
De planeación: 


Realiza un pequeño plan de trabajo que cubra los requecimientos de servicio de su 
turno. 


De administración: 
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Administra el plan de trabajo que corresponde a su turno, para que sea cubierto sin 
demoras. 


Técnicas: 


a) Se asegura de que los servicios de la red sean proporcionados exactamente en los 
horarios establecidos. 

b) Tiene a su cargo la operación de los monitores de control y la consola maestra desde 
los cuales se asegura de que los servicios planeados sean satisfechos. 

€) Llena la bitácora de servicios cubiertos en su turno, y registra eventualidades. 

d) Entrega el turno bajo continuidad de servicios, informando sobre eventualidades que 
pudieran Importar o impactar al turno que recibe, 

8) Coordina la función de los operadores de la red y del computador para que no desa- 
tiendan sus actividades, 

A Levanta los reportes de fallas de hardware y software. y comprueba su funcionalidad 
cuando éstas ya estén corregidas. 

8) Supervisa que los archivos en dispositivos magnéticos estén identificados de acuer- 
do con las normas establecidas, 

h) Lleva a cabo procedimientos de recuperación en caso de fallas de hardware y soft- 
ware, los cuales están previstos. 

A) Reúne el material necesario de diagnóstico para casos de fallas de hardware y soft- 
ware, para que sean investigadas las causas. 

7) Analiza las cargas de trabajo y mide los niveles de muliprogramación, paginación y 
actividad de los periféricos, para no saturar al computador, estableciendo las estra- 
teglas de nivelación operativa, 


PUESTO: OPERADOR DE LA RED 
DE TELEPROCESO 


Descripción 


Es responsable de mantener en línea los servicios de la red en función de los horarios 
establecidos para cada tipo de servicio. 


Desarrollo de funciones 
De planeación: 


Diariamente elabora un plan de servicio sujeto a horarios. ubicaciones y tipo de ser- 
vicios. 


De administración: 


a) Diariamente leva un registro de los usuarios, localidades. horarios y tipo de servicios 
que se proporcionaron. 

b) Diariamente leva registro de fallas y suspensiones de servicio, anexando los motivos 
que las originaron. 

c) Lleva estadísticas del servicio en línea para determinar si Jos servicios de la red son 
satisfactorios en función de las necesidades de los distintos usuarios. 
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Técnicas: 


a) Emite los comandos de control que son necesarios para poner en línea las distintas 
unidades usuarias, todo esto, de acuerdo con el plan de horarios preestablecidos. 

b) Monitorea en forma permanente el comportamiento de la red. 

©) Lleva ala práctica los procedimietos de reconfiguración de líneas en caso de fallas 
previstas, 

d) Lleva a la práctica los procedimientos de recuperación en caso de caídas de hardwa- 
re y software previstas. 

) Cierra servicios de la red de acuerdo con lo planeado para no dejar terminales acti- 
vas que en un momento determinado pudieran ser manipuladas por personas no auto- 
rizadas. 


PUESTO: OPERADOR DEL COMPUTADOR 


Descripción 


Es el responsable de mantener activos los servicios del computador central, 
Desarrollo de actividades 


De planeación: 


Eventualmente realiza las funciones de planeación encomendadas al supervisor de ope- 
ración. 


De administración: 


Eventualmente realiza las funciones de administración encomendadas al supervisor de 
operación. 


Técnicas: 


a) Opera las consolas alternas del computador para atender los requerimientos de peri- 
Téricos de cada proceso. 

b) Opera los periféricos del computador para efecto de montaje de cintas y papelería de 
Impresoras y cualquier otro medio que requiera operación manual. 

0) Mantiene la ubicación ordenada de las cintas magnéticas y las identifica en caso 
necesario. 

d Ejecuta procesos propios de operación tales como respaldos de archivos, volúmenes, 
depuración de ambiente de discos y cualquier proceso propio de operación, de acuer- 
do con los calendarios establecidos. 

€) Periódicamente hace limpieza de las unidades periféricas del computador para evitar 
fallas de grabación, lectura e impresión de reportes. 

1) Eventualmente realiza las funciones técnicas encomendadas al supervisor de 
Operación. 


PUESTO: INGENIERÍA Y SEGURIDAD DE 
INSTALACIONES DE EQUIPO 


Descripción 


Es la responsable de coordinar la instalación y cambios físicos de equipo de cómputo. 
líneas de comunicación y terminales. garantizando que reúnan los requerimientos confiables 
de seguridad para evitar accidentes o fallas constantes. 


Desarrollo de actividades 
De planeación: 


a) Participa en la planeación fisica de instalación o cambio de equipo. en conjunto con la 
gerencia de servicios de cómputo y la gerencia de desarrollo técnico, Incluyendo la 
arquitectura de la red de servicios en linea. 

b) Elabora el plan detallado para la instalación, puesta en marcha y cambios de equipo 
de cómputo, Incluyendo la red de servicios en linea. 

e) Participa on la planeación de la Instalación del equipo ambiental (energía eléctrica, 
aire acondicionado, distribución de equipo. dispositivos de seguridad. etc.). 


De administración: 


a). Lleva la administración de equipo instalado en relación con conexiones físicas, tanto 
local como remoto. 

b) Mantiene el inventario actualizado de equipo Instalado y localidades de ubicación. 

e) Mantiene Identificado cada dispositivo para conocer su interrelación conjunta. 

a Lleva registro de fallas en equipo de comunicaciones, Instalaciones eléctricas, termi- 
nales, aire acondicionado y líneas, para Investigar causas frecuentes y acciones a 
seguir, 

e) Elabora informes de compromisos adquiridos, avances, logros, requerimientos y 
cualquier dato de importancia para el gerente de servicios de cómputo. 


Técnicas: 


a) Coordina la instalación y cambios planteados de equipo, además supervisa los niveles 
de seguridad. 

b) Calcula matemáticamente los requerimientos físicos de energía eléctrica, y supervisa. 
que se mantenga en los límites de seguridad. aún con la adición de equipo nuevo. 

4) Supervisa que las instalaciones eléctricas estén conectadas en ubicaciones no ries- 
osas y con las normas de calidad confiables. 

4) Supervisa que el equipo contra incendios sea el adecuado y esté ubicado en lugares. 
estratégicos. además de que reciba el mantenimiento adecuado. 

e) Coordina la tramitación de lineas para la red del servicio de eleproceso, y considera 
las posibilidades de respaldo. 

A Coordina la reparación de lineas y se asegura de que sean confiables para reiniciar 
servicio. 

8) Atiende reportes para corregir falias mínimas de equipo e instalaciones. 

M) Coordina la instalación de terminales nuevas. 

) Coordina la reparación de terminales dañadas. 
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D Coordina simulacros de incendio, terremotos, etc., para practicar las medidas de 
seguridad. 

k) Elabora los planos de distribución. instalaciones fisicas de equipo, arquitectura de la 


red del servicio en línea. y los mantiene actualizados de acuerdo con los cambios que 
ocurran. 


PUESTO: AUXILIAR DE INSTALACIONES 


Descripción 


Es responsable de cumplir con los planes de instalación de equipo y medidas de seguri- 
dad delegados por el ingeniero a cargo del área de instalaciones. 


Desarrollo de funciones 
De planear 


Efectúa el plan de detalle propio de un trabajo delegado en él. principalmente cuando se 
trata de analizar las medidas de seguridad que deben existir en dicho trabajo. 


De administración: 


Administra las actividades de su plan de trabajo para lograr una consecución lógica y 
evitar posibles accidentes. 


Técnicas: 


a) Periódicamente realiza recorridos de observación para verificar que las instalacio- 
nes de equipo de cómputo, aire acondicionado, energía eléctrica, equipo de seguri- 
dad, equipo de comunicaciones, lineas y terminales, se encuentran en estado satis- 
factorio. 

b) Realiza un diagnóstico por cada recorrido y determina acciones a seguir. 

e) Acude a reportes de falla mínimas del equipo e instalaciones mencionados en el inciso 
a). y las corrige. 

dd) Participa en los cambios planeados para el equipo y las instalaciones que han sido 
mencionados en el inciso a). y además supervisa las normas de seguridad. 


PUESTO: JEFE DE OPERACIÓN DE SISTEMAS 


Descripción 
Es el responsable de cubrir los calendarios de producción de los sistemas liberados. 
Desarrollo de funciones 


De planeación: 
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a), Elabora el plan de producción, donde establece las cuotas de captura de datos diaria- 
mente, 
b) Elabora el plan de producción diariamente donde establece los flujos de los procesos 
por ser operados. 
e) Elabora el plan de distribución de resultados, donde establece diariamente los hora- 
rios de entrega y destinatarios, 
De administración: 
a) Lleva el control de recepción y entrega de documentos fuente para captura. 
b) Leva registro de los procesos a ser cubiertos por cada sistema liberado, 
€) Leva registro de la entrega de resultados de cada usuario. 
a) Formaliza la recepción de nuevas cuotas de documentos por capturar, y establece en 
conjunto con el usuario los horarios de recepción y entrega. 
e) Formaliza la recepción de nuevos sistemas por operar y establece en conjunto con el 
usuario los periodos y horarios de las corridas de cada proceso. 
A En conjunto con el usuario establece los horarios y periodos de entrega de resultados 


de los sistemas liberados a producción. 


PUESTO: SUPERVISOR DE CAPTURA DE DATOS 


Descripción 


Es 


el responsable de cubrir las cuotas de captura de datos, de acuerdo con la planeación 


establecida por el jefe de operación de sistemas, 


Desarrollo de funciones 


De planeación: 


En función de las cuotas por cubrir, elabora diariamente un plan de asignación de trabr jo 
de captura para garantizar su consecución. 


De administración: 


a 


Administra la recepción, asignación. recolección y entrega de documentos fuente 
para mantener su Integridad. 

Supervisa la calidad del asentamiento de datos en los documentos fuente, y levanta 
reportes en aquellos que le originan retrasos o errores de captura, para que el jefe del 
área la comunique al usuario correspondiente. 

Verifica cifras de control a fin de subsanar las diferencias detectadas. 

Coordina la trasmisión de archivos de datos en conjunto con el supervisor de opera- 
ción del computador. 

Administra las cargas de trabajo hacia el personal de captura y lleva registro de la 
productividad individual para lograr un mejor aprovechamiento, 

Lleva estadísticas de cargas de trabajo para prevenir la saturación de sus recursos. 
En las cargas pico administra la asignación a fin de cubrir, incluso. tiempos extra. 
Lleva registro de falas de equipo de captura y realiza las acciones necesarias para 
lograr una disponibilidad constante. 
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D Leva operación del equipo de captura a través de la consola maestra. 

Ñ Lleva la bitácora del turno correspondiente para lograr continuidad en la entrega a 
otros turnos. 

K) Asesora a personal de captura nuevo en el área. 


Técnicas: 


Participa en seminarios técnicos de actualización para lograr un mejor dominio del equi- 
po de captura. 


PUESTO: CAPTURISTA DE DATOS 


Descripción 
Es responsable de cubrir las cuotas de captura de datos asignados por el supervisor. 
Desarrollo de actividades 
De planeación: 
No realiza funciones de planeación. 
De administración: 
No realiza funciones de administración. 
Técnicas: 


a) Lleva el control de los documentos fuente que le asignaron para no revolverlos u ori- 
ginar omisiones de captura o duplicidad. 

b) Verifica la calidad individual de cada documento fuente por captura. y en su caso, lo 
reporta al supervisor cuando no se entienda su lectura y exista un alto riesgo de cap- 
turas erróneas. 

©) Debe poner especial cuidado en la captura para evitar reprocesos que ocasi 
desfasamientos en los horarios de compromiso. 

a) Debe cubrir en tiempo las cuotas de captura asignadas a él 

e) Regula la intensidad de su terminal para que le permita una mejor visibilidad en los 
menús de captura. 

N Reporta al supervisor Tallas que detecte en la terminal y que le impidan la rapidez 
adecuada de captura. 


PUESTO: SUPERVISOR DE CONTROL DE PROCESOS 


Descripción 


Es responsable de la operación de los sistemas en producción, de acuerdo con la planea- 
ción establecida por el jefe de operación de sistemas. 
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Desarrollo de actividades 
De planeación: 


En función de la secuencia y prioridades de los procesos, diariamente elabora el plan de 
producción detallado. 


De administración: 


a) Lleva la administración de archivos y bibliotecas que intervienen en la operación de 
los sistemas, con la finalidad de asegurar que se acceda a los apropiados. 

b) Estructura las matrices de procesos y reprocesos establecidos dentro de cada 
sistema. 

€) Codifica los procedimientos de postulados de job control, de acuerdo con la matriz de 
Control. 

h Lleva registro de fallas de proceso y los reporta al jefe de operación de sistemas. 

€) Decide las estrategias de reprocesos en las fallas predefinidas. 

A Asigna los procesos a los operadores de sistemas. 

g) Administra la producción de tal manera que cubra los horarios establecidos. 

h)_ Lleva la bitácora de control de procesos e incidencias para hacer entrega de turno. 

A Coordina la entrega de resultados a la mesa de control. 


Técnicas: 


Participa en seminarios específicos de la política de cada sistema en operación para 
tener un conocimiento más completo de sus actividades. 


PUESTO: OPERADOR DE SISTEMAS 


Descripción 
Es responsable de operar cada sistema de acuerdo con la matriz de control 
Desarrollo de actividades 
De planeación: 
Eventualmente realiza las funciones de planeación de supervisor de control de procesos. 
De administración: 
Eventualmente realiza las funciones de administración del supervisor de control de 
procesos. 
Técnicas: 


a) Accesa las bibliotecas de postulados de job control y las mantiene actualizadas en 
función del contenido de cada matriz de control. 
b) Ejecuta cada proceso en función del orden determinado en la matriz de control 
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6) Verifica las ciltas de control de cada proceso para asegurarse de su validez, 

d) Ejecuta reprocesos en caso de fallas predefinidas o de operación de procesos de 
acuerdo con la estrategia del supervisor. 

e) Prepara parámetros de control solicitados por los procesos y verifica su validez, 

f) Participa en conjunto con el supervisor en la entrega de turno para evitar malos 
entendidos. 


PUESTO: SUPERVISOR DE LA MESA 
DE CONTROL 


Descripción 


Es responsable del control de calidad. registro histórico de procesos y de la preparación 
y distribución de resultados a las distintas áreas usuarias. 


Desarrollo de actividades 


De planeación: 
Elabora diariamente un plan de trabajo a cubrir en su turno correspondiente, 
De administración: 


8) Lleva registro de los resultados y los verifica en conjunto con el supervisor de control 
de procesos, para que sean congruentes con la bitácora de procesos. 

b) Lleva registro histórico de corrida de procesos y ctas de control de cada sistema. 

©) Lleva registro histórico de entrega de resultados a Jas distintas unidades usuarias, 
considerando volúmenes, horarios y fechas. 

d) Coordina la asignación de trabajo hacia el personal. 

e) Lleva registro de resultados de mala calidad o incongruentes en cifras de control, y 
los reporta al supervisor de control de procesos para determinar causas y acciones a 
seguir. 

A) Levanta reportes de fallas en equipo de apoyo (desempapeladoras, cortadoras de 
papel, etc.) y solicita el mantenimiento necesario. 

Æ) Lleva bitácora de control correspondiente a su turno de trabajo para hacer entrega 
del turno. 


Técnicas: 


Participa en seminarios específicos de la política de cada sistema en operación. para 
tener un conocimiento más completo de sus actividades. 
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PUESTO: CONTROL DE CALIDAD 
DE RESULTADOS 


Descripción 


Es responsable de verificar que los resultados de los procesos reúnan los niveles de cali- 
dad, orden. presentación y veracidad. 


Desarrollo de actividades 
De planeación: 

No realiza funciones de planeación. 
De administración 


a) Verifica que los reportes impresos tengan la calidad suficiente de legibilidad y 
limpieza. 

b) Verifica que los reportes tengan encabezados estándares en identificación de repor- 
tes. sistema. programa. fechas correctas. usuario correspondiente, y en general 
sean perfectamente identificables. 

©) Verifica la consistencia de las cifras de control en relación con procesos anteriores. 

d) Archiva un ejemplar de las cifras de control por cada proceso para verificaciones 
futuras e investigación y rastreo de fallas de procesos. 

e) Verifica que los reportes Impresos estén en orden en relación con su número de hoja 
consecutivo. 

N Levanta reportes de inconsistencias detectadas, y las comunica al supervisor. 

8) Identifica cada reporte con destinatario, fecha y hora en que debe ser entregado. 


Técnicas: 


No realiza funciones técnicas. 


UESTO: PREPARACIÓN Y DISTRIBUCIÓN 
DE RESULTADOS 


Descripción 


Es responsable de que los usuarios reciban en tiempo los resultados de cada sistema en 
operación. 


Desarrollo de actividades 


De planeación: 
No realiza funciones de planeación. 


De administración: 


PUESTO: JEFE DE SOPORTE TÉCNICO 26 
Lleva registro de lo que recibe y distribuye. 
Técnicas: 


a) Opera el equipo de apoyo (desempapeladoras, cortadoras de papel, elc.). 

b) Lleva el control de Fallas del equipo y reportes de mantenimiento necesario. 

£) Encuaderna los tomos de reportes según lo requerido por cada usuario. 

d) Envía los tomos al usuario correspondiente, de acuerdo con las fechas y horarios 
establecidos, incluyendo usuarios foráneos. 


PUESTO: JEFE DE SOPORTE TÉCNICO 


Descripción 


Es responsable de la instalación, puesta en marcha, mantenimiento y disponibilidad con- 
tinua del software requerido para la función del computador y paquetes de apoyo para el 
desarrollo de sistemas. 


Desarrollo de funciones 
De planeación: 


a) Participa enla planeación de la configuración del equipo y el diseño de la arquitectura 
de la red de servicios en línea. 

b) Desarrolla la planeación requerida para la instalación y puesta en marcha del sofi- 
ware necesario para el funcionamiento del computador y software de apoyo para el 
desarrollo de sistemas, de manera que sea congruente con las fechas de compromiso. 

e) Desarrolla la planeación requerida para la instalación y puesta en marcha del soft~ 
ware específico para el servicio en línea, de manera que se apegue a la arquitectura. 
diseñada para la red. 

d) Desarrolla la planeación requerida para la instalación y puesta en marcha del soft- 
ware específico para el control y acceso de las bases de datos. 

e) Participa en conjunto con la gerencia de desarrollo de sistemas en la planeación del 
diseño de las configuraciones de las bases de datos. 


De administración: 


a) Lleva inventario y control de los niveles de software instalados en el computador. 

b) Lleva registro de fallas de software y realiza los reportes necesarios a los proveedo- 
res a fin de obtener las correcciones 

e) Lleva registro de los niveles de mantenimiento aplicados al software instalado en el 
computador, supervisa que se mantenga actualizado, 

d) Establece los controles necesarios para evitar caidas de servicio por errores en la 
instalación y mantenimiento de software. 

e) Leva a cabo la implantación de metodologías de trabajo dirigidas a su área de 
acción. 

A Supervisa que éstas scan respetadas en sus detalles y puesta en práctica. 

£) Administra las cargas de trabajo del personal a su cargo para evitar saturación y 
desfasamiento de proyectos. 
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h) Elabora los calendarios de compromisos y supervisa que éstos sean cubiertos. 

A Elabora informes de compromisos adquiridos, avances, logros, requerimientos y 
cualquier dato de importancia para el gerente de servicios de cómputo. 

)) Lleva estadísticas de failas para identificar las razones más frecuentes y establecer 
correctivos. 

K) Lieva estadísticas del comportamiento del equipo de cómputo en cuanto a uso de 
canales, periféricos, paginación, unidades de servicio, etc., para prevenir una posible 
saturación. 

1) Lieva la administración de los trabajos asignados a su personal de manera que se 
cubran posibles saturaciones y compromisos que no se puedan cumplir. 

m) Supervisa la correcta funcionalidad de las bases de datos. tanto por su estructura 
coma por el software que soporta su acceso. 

n) Lleva estadísticas del comportamiento de la red de servicios en línea, y verifica que 
los tiempos de respuesta sean los previstos. o en su defecto, analiza las causas y 
acciones a seguir. 

0) Evalúa el nivel técnico del personal a su cargo y se asegura que sea congruente con el 
nivel de tecnología que maneja, en su defecto, establece calendarios de capacitación 
para solitarios a la gerencia de desarrollo técnico. 

1) Establece contacto con otras Instalaciones modelo para iniciar intercambio de cono- 
cimientos y apoyo mutuo. 


Técnicas: 


Participa en seminarios técnicos de actualización para optimizar el uso de los recursos 
técnicos de la instalación. 


PUESTO: PROGRAMADOR DE SISTEMAS PARA 
EL SOPORTE TÉCNICO E INSTALACIÓN 
DE SOFTWARE EN LÍNEA 
Descripción 


Es responsable de la generación, prueba y puesta en marcha del soltware especifico de 
soporte a los sistemas del servicio en línea, 


Desarrollo de funciones 
De planeación: 
Desarrolla el plan detallado para la instalación y prueba del software en línea. 


De administración: 


Documenta la instalación de cada software. de acuerdo con los estándares establecidos 
para tal fin. 


Técnicas: 


á) Lleva a cabo la generación, prueba y puesta en marcha del sofware de soporte al 
servicio en línea. 
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b) Asesora técnicamente al personal de análisis y programación de sistemas en aque- 
llos proyectos orientados al servicio en línea. 

6) Realiza periódicamente estudios de detalle sobre el comportamiento integral de los 
servicios en línea, para detectar deficiencias en los tiempos de respuesta, y desarro- 
la las investigaciones necesarias para determinar causas y acciones a seguir. 

d) Efectúa el mantenimiento preventivo y correctivo al software en línea para garanti- 
zar una máxima disponibilidad de servicio. 

e) Efectúa los cambios necesarios al software en línea para soportar las reconfigu- 
raciones que ocurran en la red. y realiza las pruebas necesarias para su correcta 
operación. 

» Desarrolla los estándares de uso para la mejor utilización del software en línea. 

£) Efectúa los análisis necesarios sobre posibles caidas de los servicios en línea y deter- 
mina los procedimientos de recuperación en los casos donde son facuibies. 

h) Desarrolla el manual de procedimientos de recuperación, y prueba la funcionalidad de 
cada uno. 

7) Capacita al personal de operación de la red para que conozca y domine cada procedi- 
miento de recuperación. 

N Atiende reportes de caídas no recuperables del servicio en linea, e investiga causas y 
acciones a seguir. 

k) Imparte seminarios técnicos sobre métodos de uso para el software en linea. 

D Participa en la capacitación técnica para personal de nuevo ingreso. 


PUESTO: PROGRAMADOR DE SISTEMAS PARA 
EL SOPORTE TÉCNICO E INSTALACIÓN 
DE SOFTWARE LOCAL 


Descripción 


Es responsable de la generación. prueba y puesta en marcha del sistema operativo del 
computador y paquetes de apoyo en calidad de servicio local. 


Desarrollo de funciones 
De planeación: 

Desarrolla el plan detallado para la instalación y prueba del software local. 
De administración: 


Documenta la instalación de cada software. de acuerdo con los estándares establecidos 
para tal fin. 


Técnicas: 


a) Lleva a cabo la generación, prueba y puesta en marcha del sistema operativo del 
computador y paquetes de apoyo en calidad de servicio local 

b) Asesora al personal de análisis y programación para que hagan un mejor aprovecha- 
miento del software local. 

e) Realiza periódicamente estudios de detalle sobre el comportamiento de la relación 
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sistema operativo-computador. para detectar deficiencias técnicas y desarrolla las 
investigaciones necesarias a fin de determinar causas y acciones a seguir. 

a) Efectúa el mantenimiento preventivo y correctivo al software local para garantizar 
una máxima disponibilidad de servicio. 

e) Efectúa los cambios necesarios al software local fin de soportar las reconfigura- 
ciones del computador y realiza las pruebas necesarias para comprobar su fun- 
cionalidad. 

p Desarrolla los estándares de uso para la mejor utilización del software local 

8) Efectúa los análisis necesarios sobre posibles caídas en los servicios del computador, 
y determina los procedimientos de recuperación en los casos donde son factibles. 

h) Desarrolla el manual de procedimientos de recuperación y prueba la funcionalidad de 
cada uno. 

A Capacita al personal de operación del computador para que conozca y domine cada 
procedimiento de recuperación. 

) Elabora el esquema de configuración y uso de paquetes de discos. 

K) Atiende reportes de caídas no recuperables del servicio del computador e investiga 
causas y acciones a seguir. 

)) Imparte seminarios técnicos sobre métodos de uso para el sistema operativo y 
paquetes de software: de tipo local. 

m) Participa en la capacitación técnica para el personal de nuevo Ingreso, 


PUESTO: PROGRAMADOR DE SISTEMAS PARA 
EL SOPORTE E INSTALACIÓN DE 
SOFTWARE DE BASES DE DATOS 


Descripción 


Es responsable de la generación, prueba y puesta en marcha del software para servicio 
del manejo de las bases de datos. 


Desarrollo de funciones 

De planeación: 
a) Desarrolla el plan detallado para la instalación y prueba del software de bases de 
b Panica en la planeación de la estructura de las bases de datos. 

De administración: 


Documenta la instalación de cada software, de acuerdo con los estándares establecidos 
para tal fin. 


Técnicas: 


a) Lleva a cabo la generación, prueba y puesta en marcha del software para el manejo 
de bases de datos. 

b) Asesora al personal de análisis y programación para que hagan un mejor aprovecha- 
miento del sofware de base de datos. 

£) Realiza periódicamente estudios de detalle sobre el aprovechamiento técnico del 
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PUESTO: PROGRAMADOR DE SISTEMAS ZEF 


Software de base de datos para detectar deficiencias en su uso y desarrolla Jas inves- 
gaciones necesarias a fin de determinar causas y acciones a seguir. 

Elecula el mantenimiento preventivo y correctivo al software de las bases de datos 
para garantizar una máxima disponibilidad de servico. 

Efectúa los cambios necesarios al software para que soporte las reconfiguraciones 
dela arquitectura de las bases de datos y realiza las pruebas necesarias a fin de com- 
probar su funcionalidad. 

Desarrolla los estándares de uso para la mejor utilización del software de las bases 
de datos. 

Efectúa los análisis de impacto a las bases de datos en casos de caídas de servico, y 
determina los procedimientos de restablecimiento. 

Desarrolla el manual de procedimientos de recuperación y prueba la funcionalidad de 
cada uno, 

Capacita al personal de operación del computador para que conozcan y dominen 
cada procedimiento de recuperación. 

Elabora el esquema de distribución de las bases de datos en los paquetes de disco, y 
realiza los cálculos de espacio requerido. 

Alende reportes de caidas no recuperables del servicio de bases de datos. e investi- 
ga causas y acciones a seguir. 

Imparte seminarios técnicos sobre métodos de uso para el software de bases de 
datos. 

Participa en la capacitación técnica del personal de nuevo ingreso. 
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ops 


Gerencia de desarrollo 
técnico 


PUESTO: GERENCIA DE DESARROLLO TÉCNICO 


Descripción 


Es responsable de mantener a la instalación en un ambiente tecnológico actualizado que satis- 
faga los requerimientos de información de la compañía a corto, mediano y largo plazos. 


Desarrollo de actividades 
De planeación: 


a), En conjunto con la gerencia de desarrollo de sistemas y la gerencia de consultoria 
técnica, determina la planeación de requerimientos técnicos necesarios para cubrir 
los requerimientos de información de las unidades usuarias. 

b) Establece el plan maestro para Investigación de mercado con miras a adquirir el 
hardware y software con más ventajas para satisfacer los requerimientos de infor- 
mación planteados. 

e) Determina el plan de negociación con los diferentes proveedores. 

d) En conjunto con el subdirector de automatización. determina el plan presupuestal 
para la adquisición de hardware y sofware. 

e) En conjunto con el Subdirector de automatización. determina el plan presupuestal, la 
adquisición de bóvedas o cajas para seguridad de datos de la compañía. 

A En conjunto con el subdirector de automatización. determina el plan presupuestal 
para los planes de capacitación y contratación de asesores externos. 


De administración: 


a) Lleva control y registro de los gastos presupuestales y conceptos de los mismos. 

b) Realiza estudios periódicos del costo-beneficio de las inversiones. 

e) Lleva registro del hardware y software contratado, en uso y descontinuado para vis- 
lumbrar la inversión global y las amortizaciones logradas. 

d) Lleva a cabo las negociaciones de adquisición de hardware y software. 
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e) Supervisa que el hardware y software contratados estén disponibles según lo pla- 
neado. 

N) Administra el pago de las rentas de hardware y software en función de las condicio- 
nes de adquisición. 

8) Lleva registro del récord de fallas y problemas ocasionados por hardware y software 
para negociar con los proveedores sustituciones necesarias, o en su defecto, indem- 
nizaciones económicas por interrupción de servicio. 

h) Coordina los concursos de proveedores para lograr adquisiciones de hardware y 
software más ventajosas en servicio y precio. 

A Supervisa que el desarrollo tecnológico de la compañia se apegue a una estandariza- 
ción de hardware y soltware. 

À Administra la asignación de trabajos para el personal a su cargo. 

K) Prepara informes de compromisos adquiridos, avances, logros presupuestales, 
requerimientos y cualquier dato de importancia para el subdirector de automati- 
zación. 


Técnicas: 


Asiste con regularidad a presentaciones de hardware y software nuevo en el mercado, 
por considerarlo de importancia para la compañia. 


UESTO: ADMINISTRACIÓN Y SEGURIDAD 
DE ARCHIVOS Y BASES DE DATOS 


Descripción 


Es responsable de mantener la Integridad y el resguardo de los archivos criticos de la 
compañía 


Desarrollo de funciones. 
De planeación: 


a) Elabora el plan detallado para determinar el nivel de resguardo que le corresponde a 
cada archivo, con base en su importancia y complejidad de recuperación. 

b) Elabora el plan detallado para determinar el número y versiones de respaldos para 
cada archivo concentrado en el computador, así como la frecuencia de Éstos. 

e) Elabora el plan de depuración y caducidad de archivos obsoletos. 

d) Participa enla planeación de administración de espacio en paquetes de disco y volú- 
menes de cinta magnética. 

e) Participa en la planeación de la administración de las bases de datos. 


De administración: 


a) Lleva el control de resguardo de archivos locales en bóveda fuera de sitio. 

») Establece las políticas de seguridad y acceso alos lugares donde se encuentran res- 
guardados los archivos locales y en bóveda fuera de sitio. 

c) Lleva control de respaldos de archivos y supervisa la frecuencia con que éstos son 
tomados, 

d) Establece las políticas de depuración de archivos, y supervisa que se cumplan, 
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e) Leva registro de utilización de espacio en disco y uso de volúmenes de cinta para 
evitar saturaciones que pudieran retrasar procesos en producción, 

9) Analiza los requerimientos de espacio en disco y cantidad de volúmenes de cinta a 
ser utilizados por nuevos sistemas, y se asegura que no sobrepasen la capacidad 
existente; en su defecto, establece los requerimientos necesarios. 

8) Establece los estándares de identificación externa e interna para volimenes de disco 
y cintas magnéticas. 

A) Define los estándares de nomenclatura para la identificación de archivos en disco y 
cinta. 

Ď) Elabora los estándares de nomenclatura para la identificación interna de Ja estructu- 
ra de las bases de datos. 

D Lieva registro de los movimientos de afectación de las bases de datos y verifica la 
integridad, 

1), En caso de pérdida o destrucción de archivos criticos. supervisa su correcta recupe- 
ración y coordina a las distintas áreas para asegurar la validez de los datos. 

A Lleva registro de fala de proceso por inconsistencia de datos, y analiza las causas y 
acciones a seguir. 

m) Elabora informes de compromisos adquiridos, avances, logros, requirimientos y cual- 
auier dato de importancia para el gerente de desarrollo técnico. 


Técnicas; 


Participa en seminarios técnicos de actualización para conocer herramientas de softwa- 
re que garanticen mayor seguridad a los datos, y evalúa su adquisición. 


PUESTO: DESARROLLO DE MÉTODOS DE 
TRABAJO, AUDITORÍA TÉCNICA Y 
SEGUIMIENTO DE FALLAS Y PROBLEMAS 


Descripción 


Es responsable de que las actividades de todas las árcas de la subdirección de automati- 
zación estén reguladas por métodos de trabajo encauzados a obtener mayor productividad, 
orden y seguridad. 


Desarrollo de actividades 
De planeación: 


Elabora los planes de auditoría para evaluar el desarrollo de actividades por área, y se 
asegura de que los métodos de trabajo se representen y sean funcionales. 


De administración: 


a) Con base en el plan estratégico, realiza visitas de auditoría para levantar diagnósti 
cos de áreas y problema. 

b) Realiza investigaciones sobre áreas problema y establece los métodos de trabajo que 
regulen las actividades. 

©) Establece estándares de productividad por área y elabora los métodos de Irabajo 
para alcanzarlos. 
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d) Leva registro de fallas y problemas para determinar sí es por falta o deficiencia de 
métodos de trabajo, y establece acciones a seguir. 

e) Supervisa periódicamente la calidad, orden y seguridad del trabajo de cada área. 

^ Establece las normas de calidad para el trabajo de cada área. 

Æ) Lleva registro de allas y problemas, y establece el seguimiento necesario para la 
solución de cada uno. 

h) Analiza si las interfases de comunicación entre áreas están limitadas por funciones y 
responsabiidades precisas y que no existan discrepancias o confusiones. En su caso, 
determina causas y acciones a seguir. 

A Elabora informes de compromisos adquiridos, avances, logros, requerimientos y 
cualquier dato de importancia para el gerente de desarrollo técnico. 

À Analiza si el nivel técnico del personal de cada área, en su conjunto, es el suficiente 
para lograr trabajos de calidad, congruentes con la magnitud de sus funciones y res- 
ponsabilidades. En su caso, determina acciones a seguir. 


Técnicas: 


Participa en seminarios de actualización específicos de administración de centros de 
cómputo. 


'UESTO: EVALUACIÓN DE HARDWARE Y 
SOFTWARE, Y MEDICIÓN DE NIVELES 
DE SERVICIO 


Descripción 


Es responsable de la adquisición de hardware y software requerido por la instala- 
ción. cuidando que satisfaga los niveles de calidad, tecnología y volúmenes de datos a pro- 
cesar. 


Desarrollo de actividades 


De planeación: 


En conjunto con el gerente de desarrollo técnico, establece los planes de adquisición de 
hardware y software sujetos a los presupuestos. 


De administración: 


a) Elabora los estudios de justificación para la adquisición de hardware y software 
requeridos por la instalación 

b) Lleva a cabo la investigación de mercado para la obtención de hardware y software a 
fin de adquirir lo más apropiado para la instalación 

e) Coordina la recepción del hardware y software a fin de verificar que reúna las carac- 
terísticas solicitadas. 

d) Lleva un inventario actualizado de hardware y software obtenidos, y hace el análisis 
de los niveles de servicio que proporcionan. 

e) Coordina las presentaciones que los proveedores hacen sobre sus productos. 

N Hace el seguimiento con los proveedores para que sean cumplidas las fechas de 
entrega. 
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8) Supervisa que las garantías de servicio del software y hardware adquiridos sean res- 
petados por los proveedores. 

m Lieva registro sistemático de los niveles de servicio del hardware contratado, y hace 
un detallado análisis de crecimiento para vislumbrar posibles saturaciones, 

i) Elabora informes de compromisos obtenidos, avances, logros, requerimientos y cual- 
quier dato de importancia para el gerente de desarrollo técnico. 


Técnicas 


Asiste con regularidad a presentaciones de hardware y software nuevo en el mercado 
por considerarlo de Importancia para la compañía. 


PUESTO: PLANEACIÓN Y CONTROL 
DE CAPACITACIÓN TÉCNICA 


Descripción 


Es responsable de estructurar los planes de capacitación en función de las necesidades 
requeridas por cada área, para mantener un nivel de conocimientos congruentes con la tecno- 
Togia adquirida por la instalación. 


Desarrollo de funciones 
De planeación: 

Estructura la planeación básica de capacitación anual requerida por cada área. 
De administración: 


a) Hace la investigación del mercado de capacitación para seleccionar aquellas institu 
ciones que cubrirán el plan anual de capacitación. 
b) Formaliza la contratación de cursos de capacitación para asegurar las plazas nece- 
sarias de acuerdo Con los calendarios previstos. 
9 Analiza que la capacitación cubra los objetivos congruentes con los proyectos de ins- 
talación. 
9) Elabora las carreras de avance en función de la especialización de cada puesto. 
e) Lleva el registro individual de cada persona con respecto a la capacitación recibida, 
para conocer el nivel de preparación de cada integrante, 
f) Elabora el presupuesto anual requerido para cubrir los planes de capacitación. 
8) Coordina los recursos internos a ser cubiertos por personal de la propia instalación. 
h) Administra los medios para cursos y presentaciones internas. como locales, proyec- 
tores, preparación de material didáctico. etcétera. 
Coordina la capacitación técnica a usuarios de la compañía 
7) Coordina la capacitación técnica del personal de nuevo ingreso a la subdirección de 
automatización 
o, Promueve los requerimientos de contratación de personal solicitados por las áreas 
de la subdirección de automatizaci 
i Lieva a cabo los exámenes de selección para personal técnico por contratar. 
m) Lleva registro de la asignación del personal de la subdirección en relación con sus. 
puestos, y lo mantiene actualizado. 
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n) Coordina as entrevistas entre personal nuevo por contratar y responsables de área. 

0) Administra la biblioteca maestra de manuales, revistas y periódicos técnicos a los 
cuales se está Inscrito, 

P) Actualiza manuales con cambios y anexos que les llegan. 

4) Depura manuales, revistas y periódicos obsoletos. 

1) Controla manuales, revistas y periódicos técnicos que le solicitan, y los recupera. 


3) Solicita y hace el seguimiento para la obtención de manuales, revistas y periódicos 
técnicos faltantes y requeridos por las áreas. 
Técnicas: 
No realiza funciones técnicas. 
Favocio especifico de la grand de desorolloécrico 
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perra Ervin de 
Acniniración cdas a Frans y Prracióny 
do archivos ica medición de pación 
y basos de niveles de técnica 
do datos [tallas y problemas] servicio 


Índice analítico 


Actualización, 159 
Administración, 229 
en computación, objetivos de la, 
207 


Análisis, 131 


área de, 90 
Analista, 37-89, 139, 158 
del sistema, 88 
programador, 244-245 
Archivo(s) 
con resguardo 
fuera de sitio, 109 
local, 109 
de daros, problemas por falta de 
control, 108 
de entrada, número de, 92 
de salida, número de, 92 
en dispositivos 
instructivos de c ci 
nejo de, 178 
magnético, 205 
nombre de, 128n 
organización, 147 


s, 180 


Base de datos, 79, 82, 217 

administración y seguridad de ar- 
chivos y, 270-271 

estructuración, 78 
tipos, 78 

Bermúdez, L. R., 60 

Biblioteca 
Carga, 127 
lists, 127t 


de documentación desistemas, man- 
tenimiento de, 181 
Docum, 128t 
Estand, 128t 
fuente, 127t 
Gráficas, 127t 
JEL 
disp, 127t 
struc, 128t 
Macros, 127t 
Menús, 127t 
nombre de, 128n 
Objet, 127t 
Params, 127t 
Proced, 127t 
Boletines, comunicados de, 39 


Campos 
depuración de contenido de, 95 
numéricos, 156 

Capacitación, 201 
seguimiento de la, 203-208 
ventajas de la, 202 

Captura de datos, supervisor de, 258- 

259 


Capturista de datos, 259 
Carpeta 
de operación, 101, 174 
de programación, 100, 170 
del usuario, 166 
para captación de datos, 168 
Catálogo, 128n 
Centro de cómputo, 21, 41, 66, 213 
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administración, 27 
auditoría 
en el área 
de análisis y diseño de siste- 
mas, 67 
de operación, 70 
de programación, 68 
de sistemas operativos, 68 
del teleproceso, 69 
técnica, 71 
objetivo, 67, 70 
proceso, 70 
capacitación técnica para el perso- 
nal, 42 
definición, 20 
directivos, 34 
comunicación entre técnicos y, 
32 
falta de control efectivo en la asig- 
nación de 
trabajos, 37 
función, 20, 213 
grupos de servicio, 36 
inversión, 41 
jefe del, 29-30 
organización, 21, 70 
planes de capacitación, 42 
externos, 42 
internos, 42 
problemas por falta de comunica- 
ción, 41 
ión de trabajo, 40 
de consultores externos, 
7 
solicitud de, 50, 55 
técnicos, 41, 58-59 
seminarios sobre procesamiento 
de 
datos para usuarios por, 58 


satur 
servic 


Clave 
del disparados, 195 
en caso de reproceso, 195 
del procedimiento de JCL, 195 
del paso dentro, 195 
Computación electrónica 
fantasma de, 61 
técnico en, 60 


Computador, operador, 255 
función, 190 
Computadora(s), 16, 64, 78, 187 
dependencia, 19 
electrónicas, 60 
programas en, elaboración, 87 
Cómputo, gerencia de servicios de, 
251-252 
Condiciones especiales de reproceso, 
195 
tor 


de métodos y procedimientos, 248- 
249 
técnico, 249-250 
Control 
de calidad de resultados, 262 
de procesos, supervisor de 259- 
260 
Coordinador de sistemas, 242-243 
Cultura informática, 198-199 


Decisiones a nivel operativo, tipos de, 
138 
despilfarro computacional, 5-6 
Diagrama 
de bloque, elaboración, 91, 98 
de captación de información, 147 
de flujo 
dela información analizada, 141 
descripción, 141 
de procedimiento electrónico, 147, 
153 
funcional de la dirección de auto- 
matización, 240 
general, 153 
operativo del usuario, 147 
particular de procedimientos ma- 
nuales, 153 
Diagramación, 146, 153 
general del sistema de procesamien- 
to de datos, 146 
Diplomado en computación, 201, 203 
módulo 
1, 203-204 
11, 205 
111, 206 
IV, 206-207 
V, 207 


Diseño, 131 
Documento fuente 
operaciones, 137 
proceso del, 137 


Equipo de cómputo, 72 
compañías distribuidoras y fabri- 
cantes de, 72 
Errores humanos, 16 


Fechas de caducidad, manejo de, 109 
Formato de nomenclatura para la for- 


de bibliotecas, 122.128 
de grupos de acceso, 110 
para archivos 
alternos KSDS”, 114-115 
de uso universal, 116-117 
no VSAM directos, 112-113 
secuenciales, 111-112 


indexados, 112 
VSAM "ESDS”, 113 
VSAM “KSDS”, 114 


para base de datos, 115 
con información de direc- 
ción, 116 
para bibliotecas, 111 
de la clave de identificación perso- 
nal (USERID), 121 
de la identificación individual, 120 
de los nombres de archivos de 


datos, 118 
del nombre (DSNAME) individual 
para archivos, 118-120 


Formatos 
de impresión, 89 
de reportes impresos, 89 
función informática, en busca de la 
excelencia en la, 211 


Gerencia 
de consultoría técnica a usuarios, 
247-248 
estructura, 250 
del desarrollo de sistemas, 241-242 
estructura, 246 
del desarrollo técnico, 269-270 
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estructura, 274 

de servicios de cómputo, 251-252 
estructura, 268 
Grupo de acceso, 110 


Hardware y software, y medición de 
niveles de servicio, evalua- 
ción de, 272-273 

Hernández, M. E., 60 

Hoja 


de cifras de control, 89 
Se criteros de datos prueba, 89 
de definición de datos prueba, 89 


proceso, 
de identificación y objetivos del 
programa, 88 
de orden de trabajo, 88 
del diagrama general de proceso, 
88 


Impresoras, operadores, 191 
Información 
caducidad y respaldo de, 179 
fuente, recepción de, 137 
instructivo de realimentación de, 


178 
recopilada, análisis de, 141 
recorrido de, 139 
selección y *isebución de, 137 
Informática 
expertos en, 61 
instalación de, 66 
recursos de, 63 
Ingeniería y seguridad de instalaciones 
de equipo, 256-257 
Instalaciones, auxiliar de, 257 


Lenguajes, 148 

Lider de proyectos, 243-244 

LOTUS. Vease Operación de la hoja 
de cálculo 


273 INDICE ANALÍTICO 


Mesa de control 

supervisor, 261 

y resguardo de documentación, 245 
Metodología, 86 

de trabajo, definición, 83 
Microcomputadoras 

aparición de, 199 

falta de uso de las, 200 

uso de las, 198-209 


Operación 
de la hoja de cálculo, objeto, 
204 
de utilería de escritorio, 206 
del procesador de textos, objeti, 
205 
del sistema DOS, objetivo, 203 
Operaciones aritméticas, cantidad de, 
4 


Periféricos magnéticos, operadores, 190 
Procesamiento de datos 
jefe del centro de, 252-253 
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técnicos, 73 
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Red 
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de cálculo, 156 
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manejo de, 94 
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de procesamiento de datos 
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objetivos, 143 
estructura, 145 
documentación del, 162 
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entrada(s), 136, 164 
definidas o lógicas, 136 
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estructura, 246 
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núa con el nivel organizativo y finalmente se 


incluye un apéndice en el cual se presenta el 
organigrama de un centro de cómputo. 


OBRA AFÍN 


SEGURIDAD EN CENTROS 
DE CÓMPUTO 

Políticas y procedimientos 
Leonard H. Fine 


Son pocos los autores que tratan el tema de la 
seguridad en centros de cómputo de manera 
adecuada. Por lo general, sólo dirigen su aten 
ción a las áreas de seguridad física y contra 
incendios, mientras que el nivel real de seguri 
dad efectiva de las computadoras se encuentra 
por debajo de la norma aceptable, 

Considerando todos estos factores. Leonard 
H. Fine ofrece a quienes controlan y dirigen 
centros de cómputo, un nuevo enfoque sobre la 
seguridad en las computadoras: el concepto de 
seguridad total. Así, el autor proporciona los 
elementos de un método equilibrado para la 
seguridad integral en las computadoras. 


Si bien la computación está hoy en día prácticamente al alcance de 
todas las organizaciones, es muy común en nuestro país encontrar 
una subutilización de esta tecnología e. incluso, una aplicación errónea 
de la misma, lo cual tiene como consecuencia final altos costos y, en 
palabras del autor, un "despilfarro computacional". La nueva edición de 
esta obra ofrece los elementos necesarios para erradicar las | 
Ineficiencias y optimizar dichos recursos. |] 

Se decidió cambiar el anterior título, Administración de centros de 
cómputo, por el actual, Administración de la función informática, a | 
|: fin de reflejar más directamente el alcance y la importancia del tema en 

el futuro inmediato, | 

Este libro ha probado en la práctica ser muy útil como complemento | 

en la formación de los profesionales y estudiantes de informática y 

“computación y, en general, a todas las organizaciones que requieren de | 

una quía sólida para planificar la implantación y funcionamiento de los 
sistemas informáticos, | 


Capítulos destacados de este libro: 


« La administración de los centros de cómputo: una actividad urgente 

+ La importancia de evaluar los compromisos de trabajo 
+ Estandarizando la comunicación entre directivos y técnicos 
+ Beneficios de la asignación equilibrada de las órdenes de trabajo 
+ Estrategias de capacitación 

+ Formación y contratación de personal técnico 
+ Ventajas y desventajas de la consultoria extema 

+ Acercamiento entre técnicos y usuarios | 
« Auditoría técnica: ¿por qué?, ¿para qué? 

+ Administración de archivos l 
+ Análisis, diseño y mantenimiento de sistemas 

+ La productividad en la informática 

+ Operación de sistemas 

+ Usemos las microcomputadoras, ¿pero en qué? 

+ Funciones y responsabilidades del área informática 

+ En busca de la excelencia en la tunción intormática 
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